Karim asks a question with a hidden second question inside it: “Which customers spent more than the average customer in 2025?” To answer it you need the average first, which itself needs per-customer revenue. That’s three steps: revenue per customer, the average of those, then the comparison. SQL gives you two ways to nest steps, subqueries and CTEs, and the choice decides whether the next analyst can read your work.
\nYou’ve already used two of them. A derived table is a subquery in FROM that acts like a table (the per-order revenue that fixed the fan-out). A correlated subquery refers to the outer row and runs per row (the NOT EXISTS anti-join). The third is the scalar subquery: a query that returns exactly one value, usable anywhere a value is.
\nHere’s Karim’s question written with nesting only:
\nSELECT COUNT(*) AS above_average_customers\nFROM (\n SELECT o.customer_id, SUM(oi.quantity * oi.unit_price * (1 - oi.discount)) AS revenue\n FROM orders AS o\n JOIN order_items AS oi ON oi.order_id = o.order_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01' AND o.order_date < '2026-01-01'\n GROUP BY o.customer_id\n) AS r\nWHERE r.revenue > (\n SELECT AVG(revenue) FROM (\n SELECT SUM(oi.quantity * oi.unit_price * (1 - oi.discount)) AS revenue\n FROM orders AS o\n JOIN order_items AS oi ON oi.order_id = o.order_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01' AND o.order_date < '2026-01-01'\n GROUP BY o.customer_id\n )\n);It works: 140 customers. It’s also hard to read, and the revenue logic is written twice. When someone changes the definition of revenue next quarter, they’ll update one copy and not the other.
\nA common table expression names a query with WITH name AS (...), and later steps refer to it like a table:
WITH revenue_2025 AS (\n -- grain: one row per customer who bought in 2025\n SELECT o.customer_id,\n SUM(oi.quantity * oi.unit_price * (1 - oi.discount)) AS revenue\n FROM orders AS o\n JOIN order_items AS oi ON oi.order_id = o.order_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01' AND o.order_date < '2026-01-01'\n GROUP BY o.customer_id\n),\nbenchmark AS (\n SELECT AVG(revenue) AS avg_revenue FROM revenue_2025\n)\nSELECT\n COUNT(*) AS buyers,\n SUM(r.revenue > b.avg_revenue) AS above_average,\n ROUND(b.avg_revenue, 2) AS avg_revenue\nFROM revenue_2025 AS r\nCROSS JOIN benchmark AS b;Now the analysis reads like the sentence it answers: revenue per customer, the benchmark, the comparison. Revenue is defined once. And while building it you can replace the final SELECT with SELECT * FROM revenue_2025 LIMIT 5 to inspect any step, which is the single best debugging habit for long SQL. CROSS JOIN is safe here because benchmark has exactly one row. In SQLite a comparison is 1 or 0, so SUM(condition) counts TRUE rows; in PostgreSQL you’d write COUNT(*) FILTER (WHERE ...).
So 140 of 418 buyers sit above the 781.84 average. That’s typical of revenue data: a minority of large customers pulls the mean up, which is why you’ll often report the median beside it.
\n\nRania’s reorganisation request comes back: “List everyone in Peter Weber’s engineering organisation, at any level, with how far below him they sit.” A self-join gets you one level. Peter’s org has two, and another department might have five. A recursive CTE walks as deep as the data goes:
\nWITH RECURSIVE org AS (\n -- anchor: where the walk starts\n SELECT employee_id, first_name, title, 0 AS depth, first_name AS path\n FROM employees\n WHERE employee_id = 4\n UNION ALL\n -- recursive step: people who report to anyone found so far\n SELECT e.employee_id, e.first_name, e.title, org.depth + 1,\n org.path || ' > ' || e.first_name\n FROM employees AS e\n JOIN org ON e.manager_id = org.employee_id\n)\nSELECT depth, path, title\nFROM org\nORDER BY path;The structure is always the same. The anchor query runs once and produces the starting rows. The recursive query joins employees to org itself, but on each iteration it only sees the rows added by the previous iteration. Each pass adds the next level down, and the walk ends when an iteration finds nobody.
depth and path are carried through the recursion: each new row computes its values from the parent row it joined to. Sorting by path prints the result as an indented tree. The same pattern rolls costs up a category tree, follows referral chains, or expands a bill of materials.
With CTEs you can name every step. The next lesson adds a tool that lets each row see its neighbours without collapsing anything: window functions.
\n","toc":[{"id":"sec-1","text":"Three kinds of subquery","level":2},{"id":"sec-2","text":"The same analysis as CTEs","level":2},{"id":"sec-3","text":"Recursive CTEs: walking a hierarchy","level":2}],"takeaways":["A scalar subquery returns one value and can sit anywhere a value can, such as a comparison against an overall average.","A CTE (WITH name AS …) names an intermediate result so a long analysis reads top to bottom and each step can be checked on its own.","A recursive CTE has an anchor query, UNION ALL, and a recursive query that joins back to the CTE; it stops when an iteration adds no rows.","Carry a depth counter (and a path if useful) through the recursion, and cap the depth when the data might contain a cycle."],"further":[{"title":"SQLite WITH clause and recursive common table expressions","url":"https://www.sqlite.org/lang_with.html"},{"title":"PostgreSQL WITH queries","url":"https://www.postgresql.org/docs/current/queries-with.html"}],"quiz":[{"q":"Which is a scalar subquery used correctly?
","options":[{"text":"WHERE revenue > (SELECT revenue FROM revenue_2025)","why":"That subquery returns one row per customer. SQLite silently uses the first row; PostgreSQL raises an error. Either way it isn’t the average."},{"text":"FROM (SELECT AVG(revenue) FROM revenue_2025) with no alias or join","why":"That’s a derived table, not a scalar subquery, and on its own it doesn’t connect to the customers you’re filtering."},{"text":"WHERE customer_id = (SELECT customer_id FROM orders)","why":"Like the first option, the subquery returns many rows where one value is expected."},{"text":"WHERE revenue > (SELECT AVG(revenue) FROM revenue_2025)","why":"Correct. An aggregate without GROUP BY returns exactly one row and one column, so it can stand in for a single value."}],"answer":3},{"q":"What’s the main reason analysts restructure a nested query into CTEs?
","options":[{"text":"Each step gets a name and reads top to bottom, and you can run any step on its own to check it.","why":"Correct. The logic is the same; readability and testability are what improve."},{"text":"CTEs always run faster than subqueries.","why":"Engines often inline CTEs and plan them like subqueries, so performance is usually similar. Choose CTEs for clarity."},{"text":"Subqueries can’t contain aggregates, CTEs can.","why":"Subqueries can aggregate; the fan-out fix in the previous section did exactly that."}],"answer":0},{"q":"A recursive CTE starts from the CEO and joins employees e ON e.manager_id = org.employee_id. When does it stop?
manager_id is NULL.","why":"The CEO is the anchor row, where the walk starts. The walk goes downwards and ends at people with no reports."},{"text":"When an iteration produces no new rows, because the last level has no reports.","why":"Correct. Each iteration joins only the rows from the previous one; when nobody reports to anyone in that set, the recursion ends."},{"text":"When the LIMIT clause is reached.","why":"The CTE body here has no LIMIT. A LIMIT can cap recursion, but the natural stop is an empty iteration."}],"answer":2},{"q":"Why add a condition like WHERE org.depth < 20 to a recursive query over customers.referred_by?
Mark Evans (VP Operations, employee_id 2) needs his full organisation for headcount planning: everyone who reports to him directly or indirectly, not including Mark himself.
Return employee_id, first_name and depth (1 for his direct reports, 2 for their reports, and so on), sorted by depth and then employee_id. Order matters.
The starter’s anchor is already right but it stops at direct reports. Add the recursive step.
\n","hints":["A recursive CTE needsUNION ALL followed by a second SELECT that joins back to org.","Join employees AS e to org on e.manager_id = org.employee_id: people whose manager is someone already found.","Select e.employee_id, e.first_name, org.depth + 1 in the recursive step so each level is one deeper than its parent."],"explanation":"The anchor finds Mark’s three direct reports (Samir, Julia and Adam) at depth 1. The recursive step then repeatedly adds people whose manager is in the previous iteration: the three support specialists under Julia and Ben under Samir, at depth 2. The next iteration finds nobody reporting to those four, so the recursion stops with 7 people. Starting the anchor at manager_id = 2 rather than at Mark himself is what keeps him out of the result.