How this track works
Ten sessions, one database: Daybreak, a direct-to-consumer coffee-subscription brand with customers, products, orders, and subscriptions. You will query it tonight with a plain SELECT, and by session b10 you will be ranking customers with window functions, investigating a real revenue drop, and tuning queries for a warehouse. Same six tables the whole way up - so every new idea lands on data you already know.
SELECT ... FROM ...), the full Daybreak schema in your head, and a browser tab where you can run SQL against real data any time - no setup, ever.
What a relational database actually is 6 min live
Forget servers and daemons for a minute. A relational database is just a set of tables - spreadsheets with rules. Each table holds one kind of thing (customers, orders). Each row is one item; each column is one attribute. Tables link to each other through shared id columns - that is the "relational" part, and it is the whole game.
LiveWhy tables, not one giant spreadsheet3 min▶
You could cram every order, customer, and product into one enormous sheet - and teams that do regret it. Splitting into linked tables means each fact is stored once: a customer's city lives in one row of customers, not copied onto their 40 orders. Change it once, it is right everywhere. That is why relational databases have outlived nearly every technology built on top of them.
- One thing per table: customers, products, orders. If you find yourself repeating a value, it probably wants its own table.
- Keys are the glue:
customer_idinorderspoints at a row incustomers. Same value, two tables, one relationship. - SQL is how you ask questions of it: Structured Query Language - a 50-year-old, plain-ish English way to say "give me these columns, from this table, matching these rules".
The spreadsheet that broke a team. A growing shop tracked orders in one shared sheet with the customer's address typed onto every row. When a big customer moved, half the rows got updated and half did not - and their "revenue by region" report quietly went wrong for a quarter. A relational database makes that class of bug structurally impossible: the address lives in exactly one place.
Self-studySQLite, Postgres, MySQL - which SQL is this?2 min read▶
SQL is a standard, but every database engine speaks a slightly different dialect. This course runs on SQLite - a tiny, zero-setup engine that happens to compile to WebAssembly, which is exactly why the editor on this page works with no server. The good news: the core language you will learn - SELECT, WHERE, JOIN, GROUP BY, window functions - is ~90% identical across SQLite, PostgreSQL, MySQL, BigQuery, and Snowflake.
- What is universal: everything in sessions b1-b7. Learn it once, use it everywhere.
- What differs by dialect: date functions, string functions,
LIMITvsTOP, some type names. We flag these as they come up, and b10 gives you the full delta table. - Why SQLite to learn: no install, no accounts, instant feedback. The muscle memory transfers straight to your warehouse at work.
Your first query: SELECT, FROM, LIMIT 6 min live
Every SQL query, no matter how gnarly it gets later, starts with two words: SELECT (which columns you want) and FROM (which table). LIMIT caps how many rows come back so you are not staring at thousands. That is a complete, useful query.
LiveRun it now - your first live query3 min▶
Below is a real, editable SQL editor running SQLite in your browser against the Daybreak database. Press ▶ Run. Then change 5 to 15, or swap name, city for *, and run again. Nothing here can break - each run starts from a fresh copy of the database.
SELECT name, city, plan FROM customers LIMIT 5;
name, city, plan with * to see every column. Change customers to products. Raise LIMIT 5 to LIMIT 15. Each is a valid query - run and watch the table change.
LiveORDER BY - putting rows in a sensible order3 min▶
Rows come back in no guaranteed order unless you ask. ORDER BY sorts them; add DESC for high-to-low. This is the first tool that turns a raw dump into something a human reads - "most expensive products first", "newest customers first".
SELECT name, category, price FROM products ORDER BY price DESC;
Notice you did not need LIMIT here - there are only eight products, so all of them fit. On a million-row table you would keep the LIMIT while exploring.
The Daybreak schema, table by table 4 min live
Two minutes now saves you an hour later. Here is every table you will touch across the track. You do not need to memorize columns - you can always run a query to remind yourself - but knowing what lives where is the difference between fluent and frustrated.
| Table | One row is... | Key columns |
|---|---|---|
| customers | one person who bought from Daybreak | customer_id, name, city, country, signup_date, plan |
| products | one item in the catalog | product_id, name, category, price, roast |
| orders | one order placed on a date | order_id, customer_id, order_date, status, channel |
| order_items | one product line inside an order | order_id, product_id, quantity, unit_price |
| subscriptions | one recurring coffee plan | customer_id, product_id, start_date, cancel_date |
| events | one thing a customer did (login, ticket) | customer_id, event_date, event_type |
LivePeek at any table yourself2 min▶
The fastest way to learn a table is to look at a few rows. Run this, then change orders to order_items, subscriptions, or events to explore each one.
SELECT * FROM orders LIMIT 8;
products table, Equipment and Add-on rows show NULL for roast - they have no roast. NULL means "no value here", not zero and not blank. It behaves in its own special way, which is the whole of session b2's NULL lesson.
Answer a real question with SELECT ★ 12 min · everyone builds
Daybreak's founder asks: "What are our five most expensive coffees?" You have everything you need - SELECT, FROM, ORDER BY, LIMIT. Let us build the answer live, one clause at a time.
Start broad: SELECT * FROM products; - eight rows, all columns. Run it and eyeball what is there.
Trim to what you care about: swap * for name, price. Fewer columns, clearer answer.
Sort it: add ORDER BY price DESC so the priciest float to the top.
Cap it: add LIMIT 5. That is the founder's answer, and you built it in four moves.
SELECT name, price FROM products ORDER BY price DESC LIMIT 5;
This is 60% of analytics. A huge share of real "data requests" are exactly this shape: pick columns, sort, cap, hand it over. Analysts who look fast are not writing clever SQL - they are writing this simple query instantly and moving on. Fluency at the basics beats cleverness almost every day.
Your turn: three questions, your queries ★ 10 min · build your own
No scaffolding this time. Each editor below is empty-ish - write the query that answers the question, run it, fix it, run again. Getting an error is normal and fast to fix; that loop is the entire skill.
LiveQ1 · List every customer's name and signup date, newest first3 min▶
-- write your query here, then press Run SELECT name, signup_date FROM customers ORDER BY signup_date DESC;
LiveQ2 · Show the three cheapest coffees (all columns)3 min▶
SELECT * FROM products ORDER BY price LIMIT 3;
Self-studyQ3 · How many rows are in the orders table?2 min▶
A tiny taste of session b3: COUNT(*) counts rows instead of listing them. Run it - one number comes back.
SELECT COUNT(*) AS total_orders FROM orders;
Try it yourself - this week ◐ 20-30 min total
- Bookmark this page. It is your SQL scratchpad now - any query you want to test, the editors here run real SQLite in seconds.
- Write a query that lists all products in the "Coffee" category by name. (You will eyeball the category for now;
WHEREmakes it exact in b2.) - Find Daybreak's three newest customers and their cities.
- Tour every table with
SELECT * FROM <table> LIMIT 5;until the schema diagram feels obvious without looking. - Bring one question about Daybreak you cannot yet answer to session b2 - odds are it needs
WHERE, which is exactly what b2 delivers.
Official sources covered
This track teaches the working core of the major free SQL curricula, run on live data instead of screenshots. Certificates, graded problem sets, and video lectures stay on the official sites (linked in each session). This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · In a relational database, what is a "row"?
A row is one record: one customer, one order, one product. Columns are the attributes; tables hold many rows of one kind of thing.
2 · Which two words does every SQL query start with?
SELECT names the columns, FROM names the table. Everything else - WHERE, ORDER BY, JOIN - is refinement layered on that core.
3 · You see NULL in the roast column for "Cold Brew Kit". It means...
NULL means "no value here". It is not zero, not an empty string, and it follows its own rules - the heart of b2's NULL lesson.