What SQL Actually Is (and Why Every Analyst Uses It)
SQL stands for Structured Query Language, and it is the standard way to talk to relational databases. Almost every company you might work for stores its business data in a database that speaks SQL — PostgreSQL, MySQL, SQL Server, Snowflake, BigQuery, and dozens of others. The beautiful part is that the SQL you write works across all of them with only tiny syntax tweaks. This is why SQL is the most in-demand skill on data analyst job postings, even ahead of Python or visualization tools.
The other reason SQL comes first is that it answers real business questions fast. Want to know how many customers signed up last month? Which product had the highest refund rate? What is the average order value by region? SQL answers these in seconds, directly from the source of truth. You do not have to export anything, clean a file, or open a spreadsheet. You write a query, you get the answer.
What You Need Before You Start
You need three things: a SQL environment to practice in, a sample database to query, and 30 minutes a day for six weeks. That is it. No expensive software, no college course.
The single most popular free option is PostgreSQL. Download the community edition from postgresql.org and follow the installer for your operating system. The default settings are fine for learning. If installing feels heavy, use a free cloud database instead — services like Supabase, Neon, or SQLite Online let you practice SQL straight from your browser with zero setup.
Practicing SQL on an empty database is frustrating because there is nothing to ask. Download a free sample database like the Pagila demo database (a movie rental store, modeled after the classic Sakila) or the Northwind database (a product sales company). Both come with realistic tables, customers, and orders you can query right away.
A SQL client is just the editor where you type queries and see results. For local PostgreSQL, pgAdmin is the default and works well. For cloud databases, the provider gives you a web-based editor. Most modern clients offer autocomplete, query history, and result export — pick whichever feels comfortable and stick with it for the six weeks.
Do not waste a week choosing the perfect database setup. The single fastest path is SQLiteOnline.com — open it in your browser, load a sample database, and start typing queries in under five minutes. Setup time is not learning time.
Your First 10 SQL Queries (Weeks 1-2)
Start with SELECT. SELECT is how you ask a database to show you data. Every other SQL command builds on it. Here are the queries you should be able to write from memory by the end of week two.
SELECT * FROM customers; — the star means all columns. This is your hello world. Run it to confirm your database works and you can see rows.
SELECT first_name, email, created_at FROM customers; — replace the star with the exact columns you want. Always prefer this over SELECT * in real work because pulling unnecessary columns slows queries and hides intent.
SELECT * FROM customers WHERE country = 'US'; — WHERE is the filter. You can combine conditions with AND and OR: WHERE country = 'US' AND signup_date >= '2026-01-01'.
SELECT * FROM orders ORDER BY order_date DESC; — DESC means newest first, ASC means oldest first. Add LIMIT 10 to see only the top results.
SELECT COUNT(*) FROM customers; — how many customers total. SELECT AVG(order_total) FROM orders; — the average order value. These are the building blocks of every dashboard.
Single quotes for strings, double quotes for identifiers. WHERE country = 'US' is correct. WHERE country = "US" fails in PostgreSQL. Memorize this on day one — it costs an hour of debugging every week otherwise.
The Magic of JOIN (Weeks 3-4)
Real business data lives in many tables. Customers in one table, orders in another, products in a third. To answer "what did each customer buy", you have to combine them. That is what JOIN does — it stitches tables together based on a shared key.
There are four JOIN types you need: INNER JOIN keeps only matching rows, LEFT JOIN keeps all rows from the left table and adds matches where they exist, RIGHT JOIN mirrors LEFT JOIN, and FULL OUTER JOIN keeps everything from both sides. As an analyst, you will use INNER JOIN and LEFT JOIN for 95% of your work. Learn those two first.
SELECT c.first_name, o.order_date, o.total FROM customers c INNER JOIN orders o ON c.id = o.customer_id; — c and o are aliases, saving you from typing customers.customers.id repeatedly. This query gives you one row per customer-order combination.
SELECT c.first_name, COUNT(o.id) AS order_count FROM customers c LEFT JOIN orders o ON c.id = o.customer_id GROUP BY c.id, c.first_name ORDER BY order_count ASC; — this shows every customer, including those with zero orders. Essential for finding inactive users or unsold products.
You can chain JOINs: SELECT o.id, c.first_name, p.name FROM orders o JOIN customers c ON o.customer_id = c.id JOIN order_items oi ON oi.order_id = o.id JOIN products p ON oi.product_id = p.id; — this answers "what products did each customer buy". in a single query.
Think of JOIN as Venn diagrams. INNER JOIN is the overlap, LEFT JOIN is the left circle plus overlap, FULL OUTER is both circles. Drawing this out for 60 seconds before writing a JOIN saves hours of confused results.
GROUP BY and Aggregates (Weeks 4-5)
GROUP BY is how you turn rows into summaries. Every dashboard chart you have ever seen — bar chart of sales by region, line chart of users by month, pie chart of revenue by product — comes from a GROUP BY query underneath. This is the workhorse of business analysis.
SELECT country, COUNT(*) AS customer_count FROM customers GROUP BY country ORDER BY customer_count DESC; — instantly answers "where do our customers come from, ranked". Try adding WHERE signup_date >= '2026-01-01' to limit to recent signups.
SELECT region, COUNT(*) AS orders, SUM(total) AS revenue, AVG(total) AS avg_order FROM orders GROUP BY region ORDER BY revenue DESC; — three numbers per region in a single pass. This pattern shows up in almost every business review.
WHERE filters rows before grouping. HAVING filters groups after. SELECT customer_id, COUNT(*) AS orders FROM orders GROUP BY customer_id HAVING COUNT(*) > 5; — only customers who placed more than 5 orders. Essential for finding your most active users or, in reverse, your least engaged.
Every GROUP BY query follows the same shape: SELECT aggregate_columns, group_columns FROM table WHERE row_filter GROUP BY group_columns HAVING group_filter ORDER BY aggregate DESC. Write it once, change the names, and you have 80% of business analysis queries.
What to Learn After the Basics
Once the core SQL feels natural — typically week 6 — the next steps are window functions, CTEs, and query performance. These separate intermediate analysts from beginners and unlock the harder questions businesses actually ask.
Window functions let you calculate things like "rank of this customer within their their country" or "running total of revenue by month" without collapsing rows. SELECT customer_id, order_date, total, SUM(total) OVER (PARTITION BY customer_id ORDER BY order_date) AS running_total FROM orders; — this is the kind of query that turns a flat list into a real analysis.
CTEs make complex queries easier to read and debug. WITH top_customers AS (SELECT customer_id, SUM(total) AS revenue FROM orders GROUP BY customer_id) SELECT * FROM top_customers WHERE revenue > 1000; — you break the query into named steps. Senior analysts rely on CTEs for everything non-trivial.
EXPLAIN SELECT ... shows you the database's strategy for running your query. As a beginner, you do not need this daily, but learning the basics — what a sequential scan is, what an index lookup does — prevents you from shipping queries that take 10 minutes when they should take 10 milliseconds.
If you have completed the six weeks above and can write INNER JOIN, LEFT JOIN, GROUP BY, and a basic window function from memory, you are ready for actual analyst work. At that point, structured courses or guided projects move you forward faster than more self-study. Compare the top options in our course review.
Common Mistakes That Slow Beginners Down
You will make these mistakes. Everyone does. Knowing them ahead of time saves weeks.
It works in tutorials and breaks in real work. SELECT * pulls every column, including ones you do not need, and breaks when the table schema changes. Always list the columns you actually use.
WHERE runs before GROUP BY, so it filters individual rows. HAVING runs after GROUP BY, so it filters groups. Trying to use WHERE with an aggregate function is the classic beginner error and the source of half of all SQL frustration.
NULL is not zero, not empty string, not blank. It means "unknown". WHERE column = 'value' excludes NULL rows. Use WHERE column IS NULL or column IS NOT NULL when you need them. NULL handling trips up even experienced analysts occasionally.
SELECT customers.first_name, orders.order_date FROM customers INNER JOIN orders ON customers.id = orders.customer_id; — works but reads like a legal contract. Add aliases: FROM customers c INNER JOIN orders o ON c.id = o.customer_id;. Future you will thank present you.