Huda wants to feature the two best sellers from every category in the spring newsletter. You can get revenue per product with GROUP BY. But “the top two within each category” needs something GROUP BY can’t do: rank rows against their neighbours while keeping each row. That’s the job of window functions, and once you have them, a whole class of questions becomes short.
\nGROUP BY collapses each group into one row. A window function computes a value across a set of rows, the window, and attaches it to every row, collapsing nothing.
The syntax is a function followed by OVER (...). Inside the parentheses, PARTITION BY splits rows into groups, and the calculation restarts in each group; ORDER BY sets the order the function walks through. Leave out PARTITION BY and the whole result is one window.
The three ranking functions differ only in how they treat ties. Here are the most frequent UAE buyers of 2025:
\nWITH uae_orders AS (\n SELECT o.customer_id, COUNT(*) AS orders\n FROM orders AS o\n JOIN customers AS c ON c.customer_id = o.customer_id\n WHERE c.country = 'United Arab Emirates'\n AND 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)\nSELECT\n customer_id,\n orders,\n ROW_NUMBER() OVER (ORDER BY orders DESC, customer_id) AS row_num,\n RANK() OVER (ORDER BY orders DESC) AS rnk,\n DENSE_RANK() OVER (ORDER BY orders DESC) AS dense_rnk\nFROM uae_orders\nORDER BY orders DESC, customer_id\nLIMIT 8;Customers 163 and 534 both placed 11 orders. ROW_NUMBER still gives them 4 and 5, unique positions, using customer_id to break the tie. RANK gives both 4 and then jumps to 6, like a sports table. DENSE_RANK gives both 4 and continues with 5.
Pick by the question. “Exactly one row per group” (the latest order, the first visit) is ROW_NUMBER. “Top 3, and include anyone tied for third” is RANK. “The three highest values” is DENSE_RANK.
\n\nWindow functions run after WHERE, in the SELECT step, so you can’t filter on a rank in the same query’s WHERE. The standard pattern is a CTE that computes the rank and an outer query that filters it:
\nWITH ranked AS (\n SELECT\n category,\n product,\n revenue,\n RANK() OVER (PARTITION BY category ORDER BY revenue DESC) AS rnk\n FROM product_revenue\n)\nSELECT category, product, revenue, rnk\nFROM ranked\nWHERE rnk <= 2;product_revenue here stands for the per-product revenue CTE you’d write first, using the join from the joins lesson. Building it is the exercise.
The same tool answers a question Huda has wanted for months: which channel brings in new customers? That’s the channel of each customer’s first order, which is one row per partition:
\nWITH numbered AS (\n SELECT\n customer_id,\n channel,\n ROW_NUMBER() OVER (\n PARTITION BY customer_id\n ORDER BY order_date, order_id\n ) AS order_seq\n FROM orders\n WHERE status <> 'cancelled'\n)\nSELECT channel AS first_order_channel, COUNT(*) AS customers\nFROM numbered\nWHERE order_seq = 1\nGROUP BY channel\nORDER BY customers DESC;Web acquires 268 customers, the app 172 and the marketplace 63. Compare that with total orders by channel and you’ll see whether the marketplace mostly finds new buyers or serves existing ones. order_seq is also useful as a column in its own right: order_seq = 2 finds second orders, the start of every repeat-purchase analysis.
Sometimes the question isn’t “who is first?” but “which tier is each customer in?” Karim’s finance team splits customers into quartiles by lifetime revenue to compare discount usage across tiers. NTILE(n) deals the ordered rows into n buckets of near-equal size:
WITH lifetime AS (\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 GROUP BY o.customer_id\n),\ntiered AS (\n SELECT customer_id, revenue,\n NTILE(4) OVER (ORDER BY revenue DESC) AS quartile\n FROM lifetime\n)\nSELECT quartile,\n COUNT(*) AS customers,\n ROUND(MIN(revenue), 2) AS min_revenue,\n ROUND(SUM(revenue), 2) AS revenue\nFROM tiered\nGROUP BY quartile\nORDER BY quartile;The top quartile’s revenue dwarfs the bottom one, the familiar shape of almost every customer base. Notice the layering: aggregate to one row per customer, assign a tier with a window function, then group again by tier. Windows and GROUP BY aren’t rivals; most real analyses use both, in separate steps.
\nNTILE splits by row count, not by value, so customers with identical revenue can land in different buckets. For tiers with fixed thresholds (“over 2,000 is gold”), a CASE expression is the honest tool.
Ranking is one half of window functions. The other half, running totals and comparisons with the previous row, turns a monthly table into a trend, and it’s next.
\n","toc":[{"id":"sec-1","text":"Keeping rows while looking across them","level":2},{"id":"sec-2","text":"ROW_NUMBER, RANK and DENSE_RANK","level":2},{"id":"sec-3","text":"Top N per group","level":2},{"id":"sec-4","text":"First events: one row per customer","level":2},{"id":"sec-5","text":"Buckets instead of positions","level":2}],"takeaways":["A window function computes a value from a set of related rows but keeps every row, unlike GROUP BY, which collapses them.","PARTITION BY restarts the calculation for each group; ORDER BY inside OVER defines the sequence the ranking follows.","ROW_NUMBER gives unique positions, RANK leaves gaps after ties (1, 1, 3) and DENSE_RANK doesn’t (1, 1, 2).","Window functions are computed after WHERE, so to filter on a rank, compute it in a CTE and filter in the outer query.","Make ROW_NUMBER deterministic by adding a unique tie-breaker to its ORDER BY."],"further":[{"title":"SQLite window functions","url":"https://www.sqlite.org/windowfunctions.html"},{"title":"PostgreSQL window functions tutorial","url":"https://www.postgresql.org/docs/current/tutorial-window.html"}],"quiz":[{"q":"Three products have revenue 900, 900 and 700. What do RANK and DENSE_RANK (ordered by revenue descending) give the 700 product?
","options":[{"text":"RANK 3, DENSE_RANK 2","why":"Correct. RANK skips position 2 because two rows share position 1; DENSE_RANK continues with the next integer."},{"text":"RANK 2, DENSE_RANK 3","why":"That’s reversed. DENSE_RANK is the one without gaps, so it’s never larger than RANK."},{"text":"RANK 2, DENSE_RANK 2","why":"That would be true only without the tie at the top. RANK is one plus the number of rows ranked above, here 1 + 2 = 3."},{"text":"RANK 3, DENSE_RANK 3","why":"DENSE_RANK doesn’t leave gaps, so 700, the second distinct value, gets 2, not 3."}],"answer":0},{"q":"Why does SELECT ... WHERE ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY order_date) = 1 fail?
WHERE rn = 1 in the outer query."}],"answer":3},{"q":"You number each customer’s orders with ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY date(order_date)). Two orders on the same day get 1 and 2 in an unpredictable order. What’s the fix?
order_id, after the date in the window’s ORDER BY.","why":"Correct. With a unique final key the ordering is total, so the same row gets 1 every time."}],"answer":2},{"q":"How many rows does SELECT customer_id, COUNT(*) OVER (PARTITION BY customer_id) FROM orders return?
GROUP BY customer_id would return. A window function never changes the row count."},{"text":"One row with the total number of orders.","why":"That’s a plain COUNT(*) without GROUP BY or OVER."}],"answer":0}],"exercise":{"kind":"sql","starter":"-- Top 2 products by 2025 revenue in each category\nWITH product_revenue AS (\n SELECT\n c.name AS category,\n p.name AS product,\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 JOIN products AS p ON p.product_id = oi.product_id\n JOIN categories AS c ON c.category_id = p.category_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\n GROUP BY c.name, p.name\n),\nranked AS (\n SELECT\n category,\n product,\n revenue,\n ROW_NUMBER() OVER (ORDER BY revenue DESC) AS rnk\n FROM product_revenue\n)\nSELECT category, product, ROUND(revenue, 2) AS revenue, rnk\nFROM ranked\nWHERE rnk <= 2;","solution":"WITH product_revenue AS (\n SELECT\n c.name AS category,\n p.name AS product,\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 JOIN products AS p ON p.product_id = oi.product_id\n JOIN categories AS c ON c.category_id = p.category_id\n WHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\n GROUP BY c.name, p.name\n),\nranked AS (\n SELECT\n category,\n product,\n revenue,\n RANK() OVER (PARTITION BY category ORDER BY revenue DESC) AS rnk\n FROM product_revenue\n)\nSELECT category, product, ROUND(revenue, 2) AS revenue, rnk\nFROM ranked\nWHERE rnk <= 2;","orderMatters":false,"title":"Two best sellers per category","prompt":"Finish Huda’s newsletter list: the top 2 products by 2025 revenue within each category (non-cancelled orders). If two products tie for second place, keep both.
\nReturn category, product, revenue (rounded to 2 decimals) and rnk (the product’s rank inside its category, 1 = best). Row order doesn’t matter.
The starter’s product_revenue CTE is correct. Its ranking isn’t: it returns only two products for the whole store.
OVER (...) makes it restart for each category?","Add PARTITION BY category before the ORDER BY inside OVER.","Because ties should both be kept, use RANK() rather than ROW_NUMBER()."],"explanation":"Without PARTITION BY, the whole result is one window, so ROW_NUMBER numbers all products together and rnk <= 2 keeps the store’s top two. PARTITION BY category restarts the ranking in every category, and RANK gives tied products the same number so a tie for second keeps both. Kitchen and Outdoor each contain a single product, so they return one row each, and that’s the misfiled-products issue from the joins lesson showing up again.