Exercise path · SQL
10 SQL exercises, in order
From your first line to a complete program you assembled yourself. Each exercise introduces exactly one new idea, runs in this tab, and tells you in plain language what happened.
How the path works
You never start from a blank editor. Every exercise hands you a program that already runs and asks you to change or add one thing, so the first success is minutes away and the last exercise is a program you can read top to bottom and explain. The ideas arrive in this order: reading a table, filtering with where, sorting and limiting, aggregates and grouping, joins, subqueries and ctes, changing data, window functions.
Run is the check. There is no separate submit button: press Run, and the output is compared with what the exercise asked for. When it is not right, the feedback is a sentence about what happened — the line that differed, or what the error means — rather than a verdict. Hints come one at a time, and the answer opens only after you have run your code at least once, because reading the answer first is how you learn nothing.
Your finished exercises and the code you last had in the editor are saved in this browser, so a half-done exercise is still there tomorrow. Nothing is uploaded and there is no account.
The exercises
- Your First SELECTA tidy two-column listing of a tool library's shelves, produced by a query you narrowed down yourself, running against a real database inside your browser.New idea: SELECT names the columns you want back
- Pick the Right RowsA shortlist of the cheap garden tools in a lending library, produced by tightening one condition in a WHERE clause that currently returns most of the table.New idea: AND narrows a filter while OR widens it
- The Dearest ThreeA top-three listing of the highest deposits in a lending library, in a deliberate order rather than whatever order the rows came out in.New idea: ORDER BY is what makes LIMIT mean anything
- Tools per ShelfA per-shelf stocktake of a lending library — how many tools and how much deposit each shelf holds — with the one-tool shelves left out.New idea: GROUP BY splits an aggregate into one answer per group, and HAVING filters those groups
- Name the ToolA readable loan register for a tool library — who borrowed what, from which shelf, and when — built from three separate tables that each hold one part of the answer.New idea: JOIN ... ON pairs rows from two tables by a matching column
- Nobody Left OutA loans-per-member summary that includes the member who has never borrowed anything, showing her a truthful zero.New idea: LEFT JOIN keeps unmatched rows, and count(*) then miscounts them
- Above the AverageA shortlist of the tool library's heaviest borrowers — the members whose total deposit value is above the average across all members — computed in two named steps.New idea: A CTE names an intermediate result so a later step can use it
- The Missing WHEREA corrected price list for a tool library, where exactly one deposit was changed and the other four were left alone, wrapped in a transaction and checked before and after.New idea: UPDATE without WHERE changes every row, and a transaction is what makes a mistake undoable
- The Running TotalA loan ledger where each row shows both its own deposit and the total taken in up to and including that day — the shape every bank statement and sales dashboard uses.New idea: ORDER BY inside OVER turns an aggregate into a running one
- Two per ShelfA per-shelf leaderboard of a tool library's two dearest tools on each shelf — the top-N-per-group query that people learn window functions in order to write.New idea: PARTITION BY restarts a window function's numbering for each group
After the path
The SQL lessons go deeper on every idea the exercises introduced, and the practice problems are the next step up: graded against hidden tests, and a genuine challenge. Everything you can practise SQL with on this site is gathered on the SQL practice hub. The same path also exists in Python, JavaScript, TypeScript, Java, C++, C, C#, Go, PHP, Ruby, R and Bash & the Shell.