Rania’s monthly business review needs three things on one slide: revenue by month, how much of the year’s total has accumulated so far, and whether each month grew on the last. You could compute the year-to-date figure in a spreadsheet afterwards. But the same window functions that ranked products last lesson can also accumulate and compare, so the whole table comes straight out of SQL, reproducibly.
\nA window aggregate with an ORDER BY inside OVER becomes a running calculation: each row sees the rows up to itself. Add PARTITION BY and it restarts per group. Here are Cartwheel’s monthly orders with a year-to-date count that resets each January:
WITH monthly AS (\n SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders\n FROM orders\n WHERE status <> 'cancelled'\n GROUP BY month\n)\nSELECT\n month,\n orders,\n SUM(orders) OVER (\n PARTITION BY substr(month, 1, 4)\n ORDER BY month\n ) AS orders_ytd\nFROM monthly\nORDER BY month\nLIMIT 14;The partition key is the year, taken from the first four characters of the month label. December 2024 closes the year at 552 orders, and January 2025 starts again at 84.
\nTwo windows on the same row combine nicely. Dividing the running total by the total of the whole partition, 100.0 * SUM(orders) OVER (PARTITION BY substr(month, 1, 4) ORDER BY month) / SUM(orders) OVER (PARTITION BY substr(month, 1, 4)), gives the cumulative share of the year reached by each month. For a seasonal business like Cartwheel, that’s the number finance actually tracks: by the end of October 2025, the year was just under two-thirds done.
LAG(x) returns the value of x from the previous row in the window order, and LEAD(x) from the next. Period-over-period change is then simple arithmetic:
WITH monthly AS (\n SELECT strftime('%Y-%m', order_date) AS month, COUNT(*) AS orders\n FROM orders\n WHERE status <> 'cancelled'\n GROUP BY month\n)\nSELECT\n month,\n orders,\n LAG(orders) OVER (ORDER BY month) AS prev_month,\n orders - LAG(orders) OVER (ORDER BY month) AS change,\n ROUND(100.0 * (orders - LAG(orders) OVER (ORDER BY month))\n / NULLIF(LAG(orders) OVER (ORDER BY month), 0), 1) AS change_pct,\n LAG(orders, 12) OVER (ORDER BY month) AS same_month_last_year\nFROM monthly\nORDER BY month DESC\nLIMIT 4;November 2025 jumped by 193 orders, then December fell by 140: Black Friday, then the hangover. Month-over-month numbers are noisy for a seasonal business, which is why the last column uses LAG(orders, 12), the value twelve rows back, for a year-over-year view: 325 orders this November against 120 last November.
LAG(orders, 12) is only “the same month last year” if every month has a row. A month with no orders would have no row, and every comparison after it would silently shift by one month. That assumption is about to matter.
A moving average smooths daily noise. The window needs an explicit frame, the range of rows around the current one that the aggregate sees: ROWS BETWEEN 6 PRECEDING AND CURRENT ROW is the current row plus the six before it.
The frame counts rows, not days. If a day has no orders, it has no row, and the frame quietly stretches further back in time. Cartwheel’s first month shows how badly that can mislead: in January 2024 only 8 orders arrived, on 8 different days. A 7-row average over the existing rows says “1.0 orders a day” all month. The truth is about a quarter of that.
\nThe fix is a calendar: generate one row per day with a recursive CTE, LEFT JOIN the daily counts, and turn missing days into zeros:
\nWITH RECURSIVE days(day) AS (\n SELECT '2024-01-01'\n UNION ALL\n SELECT date(day, '+1 day') FROM days WHERE day < '2024-01-31'\n),\ndaily AS (\n SELECT date(order_date) AS day, COUNT(*) AS orders\n FROM orders\n WHERE status <> 'cancelled'\n AND order_date >= '2024-01-01' AND order_date < '2024-02-01'\n GROUP BY day\n),\nfilled AS (\n SELECT d.day, COALESCE(x.orders, 0) AS orders\n FROM days AS d\n LEFT JOIN daily AS x ON x.day = d.day\n),\nsmoothed AS (\n SELECT day, orders,\n ROUND(AVG(orders) OVER (\n ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW\n ), 2) AS orders_7d_avg\n FROM filled\n)\nSELECT * FROM smoothed\nWHERE day >= '2024-01-25'\nORDER BY day;Now 31 January shows 0.43 orders a day over the last week, the honest number. Notice where the date filter sits: in the final SELECT, after the moving average is computed in smoothed. Window functions run after WHERE, so filtering in the same query would leave the first displayed days with no history to average. The same calendar trick protects LAG(orders, 12) from missing months.
You can now rank, accumulate and compare. The next lesson puts these tools to work on the two analyses every product team asks for: funnels and cohort retention.
\n","toc":[{"id":"sec-1","text":"Running totals and year-to-date","level":2},{"id":"sec-2","text":"Comparing with the previous row","level":2},{"id":"sec-3","text":"Moving averages and the frame","level":2}],"takeaways":["SUM(x) OVER (ORDER BY period) is a running total; adding PARTITION BY year makes it reset each year, which is year-to-date.","LAG(x) reads the previous row’s value and LEAD(x) the next one, so period-over-period change is x - LAG(x).","A moving average needs an explicit frame, such as ROWS BETWEEN 6 PRECEDING AND CURRENT ROW, and a row for every period, including empty ones.","Window functions run after WHERE, so filter the displayed range in an outer query or the window will only see the filtered rows."],"further":[{"title":"SQLite window functions, frame specifications","url":"https://www.sqlite.org/windowfunctions.html#frame_specifications"},{"title":"PostgreSQL window function calls","url":"https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS"}],"quiz":[{"q":"SUM(revenue) OVER () is added to a monthly revenue table. What does every row show?
Monthly orders are 84, 63 and 70 for January to March. What does orders - LAG(orders) OVER (ORDER BY month) return for January, February and March?
LAG(orders, 1, 0), only if 0 is truly the right baseline."}],"answer":2},{"q":"Daily orders are missing on days with no sales. What’s wrong with AVG(orders) OVER (ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) on that table?
This query should show a 7-day moving average for the last week of December only. Why are the first values too low?
\nSELECT day, AVG(orders) OVER (ORDER BY day ROWS BETWEEN 6 PRECEDING AND CURRENT ROW)\nFROM filled_days\nWHERE day >= '2025-12-25';Build the slide table for Rania: one row per month of 2025 (non-cancelled orders) with month (‘YYYY-MM’), revenue, running_revenue (revenue accumulated from January up to and including that month) and mom_change (this month’s revenue minus the previous month’s; NULL for January). Round the money columns to 2 decimals and sort by month. Order matters.
The monthly CTE is correct. Both window columns in the final SELECT are wrong.
running_revenue shows the same number. What’s missing inside OVER ()?","Use SUM(revenue) OVER (ORDER BY month) for the running total.","LEAD looks at the next row. To compare with the previous month, use revenue - LAG(revenue) OVER (ORDER BY month)."],"explanation":"An empty OVER () makes one window containing all twelve months, so the starter printed the annual total on every row. Adding ORDER BY month turns it into a growing window, which is a running total. For month-over-month change you need the previous row, which is LAG; LEAD compared each month with the following one and left December NULL instead of January. December’s running revenue equals the year’s total, a free reconciliation check against the category table from the joins lesson.