Yara, the senior analyst on your team, reviews every query before it reaches a stakeholder. Her first comment on new analysts’ work is rarely about the logic. It’s “I can’t check this quickly.” Her second, this quarter, is practical: Cartwheel is moving its reporting to a PostgreSQL warehouse, and every query you’ve written needs to survive the move. This lesson covers both: SQL that reviewers can read, and SQL that travels.
\nHere’s a real query from the support team’s old dashboard. It runs and returns plausible numbers:
\nselect t.channel,count(*),avg(satisfaction) from support_tickets t,customers c where t.customer_id=c.customer_id and closed_at is not null and opened_at>='2025-01-01' group by 1 order by 3 desc;A reviewer has to work to answer basic questions. Why is customers here? (It isn’t used; it’s leftover from an earlier version, and it’s a join someone must now reason about.) Is that a join condition or a filter? Which table does satisfaction belong to? What is column 3? Is the 2025 filter missing an upper bound or is that deliberate? Here’s the same analysis, written to be checked:
-- Support satisfaction by contact channel, tickets opened in 2025.\n-- grain: one row per channel. Only closed tickets: open ones can't be rated yet.\nSELECT\n t.channel,\n COUNT(*) AS closed_tickets,\n COUNT(t.satisfaction) AS rated,\n ROUND(AVG(t.satisfaction), 2) AS avg_satisfaction\nFROM support_tickets AS t\nWHERE t.closed_at IS NOT NULL\n AND t.opened_at >= '2025-01-01'\n AND t.opened_at < '2026-01-01'\nGROUP BY t.channel\nORDER BY avg_satisfaction DESC;The changes, in order of importance:
\nJOIN ... ON, never a comma plus a WHERE condition. The join condition then sits next to the table it belongs to.GROUP BY 1 is a contested convenience; names survive edits to the SELECT list.rated sits next to the average, the response-rate lesson from Section 1.Uppercase keywords, leading or trailing commas, and indentation width are team conventions. Pick one, apply it everywhere, and let a formatter enforce it. Consistency matters far more than which style wins.
\n\nSQL is a standard, but every engine has its own functions and its own leniency. Almost everything in this course runs unchanged in PostgreSQL: joins, CTEs, recursive CTEs, window functions, FILTER, NULLIF, COALESCE, IS DISTINCT FROM. The differences cluster in a few places:
| Task | \nSQLite | \nPostgreSQL | \n
|---|---|---|
| Month label | \nstrftime('%Y-%m', d) | \nto_char(d, 'YYYY-MM') | \n
| Start of month | \ndate(d, 'start of month') | \ndate_trunc('month', d) | \n
| Add an interval | \ndate(d, '+7 days') | \nd + INTERVAL '7 days' | \n
| Hours between | \n(julianday(b) - julianday(a)) * 24 | \nEXTRACT(EPOCH FROM b - a) / 3600 | \n
| Case-insensitive match | \nLIKE (ASCII) | \nILIKE | \n
| Two-way choice | \nIIF(c, a, b) or CASE | \nCASE | \n
| Count a condition | \nSUM(cond) or FILTER | \nCOUNT(*) FILTER (WHERE cond) | \n
The biggest change is underneath the table. PostgreSQL has real date and timestamp types, so date columns are compared as dates, and date arithmetic returns intervals rather than numbers. Booleans are a real type too: SUM(status = 'cancelled') fails there because you can’t sum a boolean, which is why FILTER is the portable choice.
Two smaller differences catch people regularly. Integer division truncates in both engines (7 / 2 is 3), so keep writing 100.0 * for percentages. And PostgreSQL sorts NULLs last in ascending order where SQLite sorts them first, so add NULLS FIRST or NULLS LAST whenever NULL placement matters.
The exercise is a real porting job: a warehouse query that fails in SQLite. After that, the capstone puts the whole course together.
\n","toc":[{"id":"sec-1","text":"A query someone else has to check","level":2},{"id":"sec-2","text":"From SQLite to PostgreSQL","level":2}],"takeaways":["Readable SQL uses explicit JOIN … ON, one column per line, role-based aliases, named CTE steps and comments that explain why, not what.","Remove what the query doesn’t use, such as unused joins and SELECT *, because every extra table is a possible fan-out and a question for the reviewer.","[object Object]","SQLite is more lenient than PostgreSQL (bare columns, case-insensitive LIKE, booleans as 0/1), so a query that runs in SQLite may fail or behave differently in PostgreSQL."],"further":[{"title":"SQLite quirks, caveats and gotchas","url":"https://www.sqlite.org/quirks.html"},{"title":"PostgreSQL date/time functions and operators","url":"https://www.postgresql.org/docs/current/functions-datetime.html"},{"title":"PostgreSQL pattern matching (LIKE and ILIKE)","url":"https://www.postgresql.org/docs/current/functions-matching.html"}],"quiz":[{"q":"FROM support_tickets t, customers c WHERE t.customer_id = c.customer_id appears in a query that never uses any c. column. What should the reviewer ask for?
Which SQLite expression has a direct PostgreSQL equivalent in date_trunc('month', order_date)?
julianday(order_date)","why":"julianday converts to a day number; it doesn’t truncate to the month."},{"text":"strftime('%w', order_date)","why":"That’s the weekday number, not the start of the month."},{"text":"date(order_date, '+1 month')","why":"That adds a month; the PostgreSQL equivalent is order_date + INTERVAL '1 month'."},{"text":"date(order_date, 'start of month')","why":"Correct. Both return the first day of the order’s month. PostgreSQL returns a timestamp, SQLite returns ‘YYYY-MM-01’ text."}],"answer":3},{"q":"This runs in SQLite: SELECT channel, status, COUNT(*) FROM orders GROUP BY channel. What happens in PostgreSQL?
status is neither grouped nor aggregated.","why":"Correct. PostgreSQL enforces the GROUP BY rule that SQLite relaxes, so the bare-column bug becomes an error you can’t miss."},{"text":"It returns the same result as SQLite.","why":"PostgreSQL refuses to pick an arbitrary value for a bare column."},{"text":"It returns one row per channel and status.","why":"That would need GROUP BY channel, status; PostgreSQL doesn’t add grouping columns for you."}],"answer":0},{"q":"WHERE email LIKE '%@EXAMPLE.COM' finds all 600 customers in SQLite. How many does it find in PostgreSQL, where emails are stored in lower case?
Huda found this query in the PostgreSQL warehouse and wants the same numbers from Cartwheel’s SQLite database: for customers in Dubai, one row per month of 2025 with month (‘YYYY-MM’), orders (non-cancelled orders) and app_orders (those placed through the mobile app). Sort by month. Order matters.
The starter fails in SQLite. Translate every PostgreSQL-only piece into SQLite and keep the logic the same.
\n","hints":["Run it and read the first error. Then look for each PostgreSQL feature::: casts, to_char, date_trunc, ILIKE and DATE '...' literals.","A ‘YYYY-MM’ month label in SQLite is strftime('%Y-%m', o.order_date). Dates are ISO text, so the date literals become plain strings.","SQLite’s LIKE is already case-insensitive for ASCII, so ILIKE becomes LIKE. COUNT(*) FILTER (WHERE ...) works in both engines and can stay."],"explanation":"Four things are PostgreSQL-only: the ::timestamp cast, to_char with date_trunc, ILIKE, and typed DATE '...' literals. In SQLite the month label is strftime('%Y-%m', ...), ISO text needs no cast, and LIKE already ignores ASCII case. FILTER is standard SQL and works unchanged. Notice the reverse trap if this query ever goes back: SQLite’s LIKE 'MOBILE%' matches ‘mobile_app’, but in PostgreSQL that LIKE would match nothing, which is why the original used ILIKE. Dubai’s busiest month was December, with 23 orders.