Learn · sql
How you ask a warehouse questions, and how you shape it so the answers are right.
Start with what data and databases are, then learn SELECT, JOINs, window functions, star schemas, and a fact-table capstone in the SQL editor.
Core foundational modules are free. Advanced production modules need Pro.
Playable walkthroughs: watch the system move, predict the next step, stamp a memory seal, then practice. Completing a Trace counts toward readiness.
Free Trace
Window functions
Keep every row. Add the group's context.
Opens in Window functions (the DE benchmark)
Pro Trace
SCD Type 2
History is a new row, not an overwrite
Opens in Slowly Changing Dimensions Type 1 / 2 / 3
Pro Trace
Star schema and grain
Say the grain in English before you draw boxes
Opens in Star schema: facts, dimensions, grain
Imagine the business asks a simple question: what was revenue last month, by country, excluding refunds. The data for that answer sits in four tables written by three different teams. One of those tables has two rows per order because a retry inserted a duplicate. If you get the join wrong, you report a number that is twice as large as reality, and somebody makes a decision on it. SQL is the language for getting that right, and warehouse modelling is how you stop the same mistake recurring every month.
SQL is the one skill that appears in every data engineering interview and every working day. You will read more SQL than you write, most of it written by somebody who has left the company, and you will be asked why a dashboard number changed.
No database experience
The track opens with what data and a table actually are, before any query appears.
Helpful but optional: basic Python
Not required for any lesson here. Queries run in the SQL editor in your browser.
5 stages, in the order they build on each other. Each stage lists the modules and lessons it covers, and what you should be able to do by the end of it.
Terminology like row, column, primary key, and grain gets used casually by everyone around you. If those words are fuzzy, every later lesson is guesswork.
Understanding DataFree
0/4
What data is, what databases are, and why tables have rows and columns. The vocabulary you need before writing SQL.
Module Checkpoint
1 conceptual questions to verify mastery
By the end of this stage
You can look at a table and say what one row represents, which is the single most useful habit in this whole track.
Ninety percent of working SQL is SELECT, WHERE, GROUP BY, and JOIN. The goal here is not exposure, it is fluency, because these are the tools you use every day.
Relational coreFree
0/5
SELECT, WHERE, GROUP BY, and JOIN: the four operations every SQL query uses.
Module Checkpoint
3 conceptual questions to verify mastery
By the end of this stage
You can answer a business question that spans three tables and defend why your join does not duplicate rows.
Where people get stuck
Joins are where beginners produce confidently wrong numbers. If a join makes your row count go up unexpectedly, stop and find out why before continuing.
Some questions cannot be answered by collapsing rows: rank customers within each region, find the running total, compare each row to the previous one. GROUP BY throws away exactly the rows you need.
Windows, cleaning & opsFree preview
0/5
The DE benchmark: window functions, cleanup, dedupe, and reading EXPLAIN.
Module Checkpoint
1 conceptual questions to verify mastery
Advanced Querying
0/4
Set operations, recursive CTEs, JSON, and pivot patterns on the warehouse tables.
By the end of this stage
You can write window functions without looking up the syntax, and you know when a CTE makes a query readable rather than just longer.
Where people get stuck
NULL behaviour breaks more queries than complex logic does. NULL is not zero and not empty, and it makes both comparisons and aggregates behave in ways that surprise people.
Querying well is not enough. If the tables themselves are shaped badly, every analyst will keep double-counting revenue and you will keep explaining why. This stage is how you shape them.
Warehouse & Dimensional Modeling
0/6
OLTP vs OLAP, star schemas, surrogate keys, SCD 1/2/3, additive facts, and denormalization tradeoffs.
By the end of this stage
You can design a fact table and its dimensions, state the grain out loud, and handle a dimension whose values change over time.
Where people get stuck
Slowly changing dimensions are the classic interview topic here, and the classic real-world mess. Learn type 1 versus type 2 properly.
A query that works on ten thousand rows and dies on ten million is not finished. This is where you learn to read what the engine is actually doing.
Performance & Production SQL
0/5
Join strategies, warehouse partitioning, views, constraints, and a star-schema capstone.
By the end of this stage
You can read a query plan, explain why a query is slow, and say which change will help before you make it.
Finishing the lessons is not the goal. These are the things you should be able to do afterwards, and each one is worth checking honestly.
30 minutes a day
about 12 sessions
1 hour a day
about 6 sessions
4 hours a weekend day
about 2 sessions
SQL rewards short daily reps far more than long weekend sessions. Twenty minutes of writing queries every day for three weeks will take you further than three full Saturdays. Run every query in the editor rather than reading it, because SQL that looks obvious on a page is where the surprises hide.
These counts cover reading and the built-in exercises only. Real practice on the drills and a capstone will add to it, and that time is where most of the learning happens.
| Common mistake | What to do instead |
|---|---|
| Memorising syntax without ever checking row counts. | After every join, check whether the row count changed as you expected. This one habit prevents most reporting errors. |
| Treating SELECT DISTINCT as a fix for duplicates. | DISTINCT hides a join problem rather than solving it. Find where the extra rows came from. |
| Learning window functions as three syntax examples. | Learn the mental model: the window stays open, the rows survive. Then the syntax follows on its own. |
| Skipping the modelling module because querying feels more practical. | Modelling is what senior interviews probe. Anyone can write a SELECT, few can defend a grain. |