Learn SQL for Data Analysis: A Roadmap That Follows the Job

What analysts actually do with SQL all day

Strip away the job title and a data analyst's SQL work is a short list of moves, repeated with different tables: pull every order from last quarter, keep only the ones from a region, group them by month, compare this year against last, then join in the customer table because the follow-up question always asks "and which of those were repeat buyers?". The roadmap below is just that list, ordered so each move lands when you are ready for it.

The order to learn it in

1. Asking simple questions (weeks 1–2). SELECT, FROM and WHERE, plus patterns, ranges and missing values, then sorting and limiting results. By the end of week two you can answer questions like "show me every refund over $50 this month", which is already real work.
2. Summarising (week 3). Aggregate functions, then GROUP BY and HAVING. This is where rows turn into answers: revenue by product, signups by week, average order value by country. Half of all dashboard numbers are this stage and nothing else.
3. Joining tables (weeks 4–5). Real data never lives in one table. INNER JOIN first, then outer, cross and self joins, with a clear picture of keys and relationships. Joins are the skill that separates "has done a SQL course" from "can do the job", so give them two full weeks.
4. Questions inside questions (week 6). Subqueries, set operations and CASE. CASE in particular pays for itself immediately: it is how analysts bucket ages, label customers as new or returning, and turn raw values into readable categories.
5. Window functions (weeks 7–8). Running totals, rankings and comparisons against the previous row, calculated without collapsing your data the way GROUP BY does. This is the stage interviewers probe and the one most tutorials rush. Take your time here.
6. Working knowledge of the rest (week 8 and after). Views as saved questions, a plain understanding of indexes and transactions, and enough database design to know why tables are split the way they are. You will rarely design databases as an analyst, but you will read other people's designs every day.

How to practise so it sticks

Syntax fades within a week if you only read it. What keeps it is questions. Take one dataset with two or three related tables, an online shop works well, and write down 20 questions a manager might ask: best-selling product by month, customers who ordered twice but never a third time, revenue lost to refunds by category. Then answer all 20 in SQL, by hand, before checking anything. Keep every query in a file with the question written above it as a comment. That file becomes both your memory and, later, your interview revision notes.

Resist the urge to learn three database systems at once. SQLite, MySQL and PostgreSQL differ in small print, not in the thinking. Pick one, finish the roadmap, and the others become a weekend's worth of differences rather than three half-learned languages.

How long it takes, honestly

At 30 minutes a day, expect to pull and summarise data with confidence inside three to four weeks, joins included. Window functions land around week eight. That is fast compared with most technical skills, and it is why SQL is the sensible first move for data work: eight weeks from now you can hold your own in the part of the job that fills most of the day.

Three mistakes that waste months

• Starting with table creation. CREATE TABLE and data types matter to engineers. Analysts read tables far more than they build them, so creation belongs late in the roadmap, not on day one.
• Collecting syntax without data. A memorised list of functions answers nothing. Every new clause should meet a real table within the hour.
• Practising on one tidy table. Tidy single-table exercises end right where the job begins. If your practice data has no second table to join, it is not practice for analysis.