Mark from Operations is back with the question you couldn’t answer last lesson: “What’s our average resolution time, by priority?” You know how to compute one ticket’s hours. Now you need one row per priority, each summarising dozens of tickets. That’s what GROUP BY does, and the idea underneath it, the grain of a result, is the single most useful concept in analytical SQL.
Every table and every result has a grain: the thing one row represents. support_tickets has one row per ticket. Mark wants one row per priority. Write that down first, then make the query match it:
SELECT\n priority,\n COUNT(*) AS tickets,\n COUNT(closed_at) AS closed,\n ROUND(AVG((julianday(closed_at) - julianday(opened_at)) * 24), 1) AS avg_hours,\n ROUND(MAX((julianday(closed_at) - julianday(opened_at)) * 24), 1) AS max_hours\nFROM support_tickets\nGROUP BY priority\nORDER BY avg_hours;Four rows, one per priority, which matches the grain you stated. Urgent tickets close in 6.5 hours on average, high in about a day, and low and normal in over three days. Notice how COUNT(closed_at) and AVG quietly skip open tickets, exactly as the previous lessons promised. The max_hours column matters too: an average can look healthy while one customer waited a week.
That diagram explains most GROUP BY errors. WHERE runs before groups exist, so it can’t test COUNT(*); that’s HAVING’s job. ORDER BY runs after SELECT, so it can always use a column alias. SQLite and PostgreSQL also accept an alias in GROUP BY as a convenience, which is why GROUP BY month works below, but the logical order is still the one shown.
Karim in Finance wants to know which products have sold at least 100 units at full price, with no discount. Units per product is an aggregate, so the threshold goes in HAVING. “No discount” is a property of each order line, so it’s a row condition and goes in WHERE:
SELECT\n product_id,\n SUM(quantity) AS units,\n COUNT(DISTINCT order_id) AS orders\nFROM order_items\nWHERE discount = 0\nGROUP BY product_id\nHAVING SUM(quantity) >= 100\nORDER BY units DESC\nLIMIT 5;Read it in the diagram’s order: drop discounted lines, group what’s left by product, keep products with 100+ units, then compute, sort and cut. COUNT(DISTINCT order_id) counts orders rather than lines, because in Cartwheel’s data each product appears at most once per order, so lines and orders differ only when you count across products.
Huda in Marketing asks what share of each month’s orders came through the mobile app. You need two counts per month, all orders and app orders. A FILTER clause restricts one aggregate to some rows:
SELECT\n strftime('%Y-%m', order_date) AS month,\n COUNT(*) AS orders,\n COUNT(*) FILTER (WHERE channel = 'mobile_app') AS app_orders,\n ROUND(100.0 * COUNT(*) FILTER (WHERE channel = 'mobile_app') / COUNT(*), 1) AS app_pct\nFROM orders\nWHERE order_date >= '2025-07-01'\n AND order_date < '2026-01-01'\nGROUP BY month\nORDER BY month;The app share moves between roughly 28% and 40%, and November’s volume is more than three times July’s, thanks to Black Friday. Two details matter. 100.0 rather than 100 forces decimal division; SQLite divides integers as integers, so 47 / 129 is 0. And FILTER is standard SQL, supported by SQLite and PostgreSQL. In engines without it, write SUM(CASE WHEN channel = 'mobile_app' THEN 1 ELSE 0 END), which is the same count spelled the long way.
Once a grouped query runs, verify it before reporting:
\nNone of these checks takes more than a minute, and together they catch the majority of grouping mistakes before a stakeholder does. Make them part of the loop from the first lesson, between “query” and “answer”. That third check becomes vital in the next lessons, when you start joining tables. Joins can change the grain without telling you, and summing over the wrong grain is how double counting starts.
\n","toc":[{"id":"sec-1","text":"One row per what?","level":2},{"id":"sec-2","text":"WHERE versus HAVING","level":2},{"id":"sec-3","text":"Counting a subset inside each group","level":2},{"id":"sec-4","text":"Checking the grain","level":2}],"takeaways":["The grain of a result is what one row represents; say it out loud before writing GROUP BY and check it after.","Every column in the SELECT list should be either in GROUP BY or inside an aggregate; SQLite allows bare columns but fills them from an arbitrary row.","WHERE filters rows before grouping, HAVING filters groups after aggregation, so conditions on SUM or COUNT belong in HAVING.","COUNT(*) FILTER (WHERE …) or SUM(CASE WHEN … THEN 1 ELSE 0 END) counts a subset inside each group without a second query."],"further":[{"title":"SQLite aggregate functions","url":"https://www.sqlite.org/lang_aggfunc.html"},{"title":"SQLite SELECT processing, including bare columns","url":"https://www.sqlite.org/lang_select.html#resultset"},{"title":"PostgreSQL aggregate expressions and FILTER","url":"https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-AGGREGATES"}],"quiz":[{"q":"You need countries whose 2025 order count is above 50. Where does each condition go?
","options":[{"text":"Both the year test andCOUNT(*) > 50 go in WHERE.","why":"WHERE runs before grouping, when no count exists yet, so an aggregate there is an error."},{"text":"Both go in HAVING.","why":"PostgreSQL rejects a non-grouped order_date in HAVING, and SQLite would test the date of one arbitrary row per group, giving silently wrong counts. The year test is a row condition and belongs in WHERE."},{"text":"The year test goes in HAVING; COUNT(*) > 50 goes in WHERE.","why":"That’s reversed. WHERE can’t see aggregates at all."},{"text":"The year test goes in WHERE; COUNT(*) > 50 goes in HAVING.","why":"Correct. Filter rows first (only 2025 orders), then filter the groups by their aggregate."}],"answer":3},{"q":"What is the grain of this result?
\nSELECT customer_id, strftime('%Y-%m', order_date) AS month, COUNT(*)\nFROM orders\nGROUP BY customer_id, month;In SQLite, SELECT channel, status, COUNT(*) FROM orders GROUP BY channel runs without error. What does the status column show?
GROUP_CONCAT(status) (or string_agg) does; a bare column is a single value."}],"answer":0},{"q":"Which expression gives the share of each month’s orders that were cancelled, as a percentage?
","options":[{"text":"COUNT(status = 'cancelled') * 100.0 / COUNT(*)","why":"COUNT counts non-NULL values, and status = 'cancelled' is 0 or 1, never NULL, so this counts every row and returns 100."},{"text":"100.0 * COUNT(*) FILTER (WHERE status = 'cancelled') / COUNT(*)","why":"Correct. FILTER restricts that one aggregate to cancelled rows; 100.0 avoids integer division."},{"text":"COUNT(*) / COUNT(*) FILTER (WHERE status = 'cancelled')","why":"That’s the inverse ratio, and with integer division in SQLite it would truncate as well."}],"answer":1}],"exercise":{"kind":"sql","starter":"-- Best-selling products: at least 130 units\nSELECT\n product_id,\n SUM(quantity) AS units,\n ROUND(SUM(quantity * unit_price * (1 - discount)), 2) AS revenue\nFROM order_items\nORDER BY units DESC;","solution":"SELECT\n product_id,\n SUM(quantity) AS units,\n ROUND(SUM(quantity * unit_price * (1 - discount)), 2) AS revenue\nFROM order_items\nGROUP BY product_id\nHAVING SUM(quantity) >= 130\nORDER BY units DESC, product_id;","orderMatters":false,"title":"Karim's best sellers","prompt":"Karim wants every product that has sold at least 130 units across all order lines (ignore order status for now).
\nReturn one row per product with product_id, units (total quantity) and revenue (sum of quantity * unit_price * (1 - discount), rounded to 2 decimals). Row order doesn’t matter.
The starter returns a single row. Make it return the right grain and apply the threshold.
\n","hints":["State the grain: one row per product. Which clause makes that happen?","AddGROUP BY product_id. Now every product appears; you need to keep only some groups.","A condition on SUM(quantity) can’t go in WHERE. Use HAVING SUM(quantity) >= 130."],"explanation":"Without GROUP BY, SQLite aggregates the whole table into one row and fills the bare product_id from an arbitrary line, so the starter shows one product next to the company-wide total. GROUP BY product_id sets the grain to one row per product, and HAVING filters those groups after the sums exist. Eleven products clear the bar. The Standing Desk 140cm (product 21) has only 132 units but more than 60,000 in revenue, a reminder that units and revenue rank products very differently.