2Course 2FoundationsBeginner
SQL for Analysts
Write the queries you keep asking the data team for, on the tables your company already has.
- Chapters
- 12
- Time
- 10 hours
- Format
- Self-paced
- Tools
- PostgreSQL, BigQuery, Redshift, or MySQL; a browser-based sandbox is included
What you will be able to do
- Write SELECT, WHERE, GROUP BY, and ORDER BY against real business tables without looking anything up.
- Join orders to customers to payments and know which join type answers which question.
- Use window functions for running totals, rankings, first and last events, and per-customer velocity.
- Handle dates and timezones, including IST cut-offs and month boundaries, without off-by-one errors.
- Turn a working query into a saved view your team can reuse.
Chapters
12 chapters. Chapter 1 is free below.
- 1
Tables, rows, keysFree to read
How business data is laid out, and the ids that connect orders, customers, and payments.
- 2
SELECT and WHERE
Filtering, sorting, limiting. Reading the shape of a table before you trust it.
- 3
GROUP BY and aggregates
Counts, sums, averages, and grouping by day, week, month.
- 4
Dates and timezones
Truncation, intervals, IST versus UTC, and the classic month-boundary bug.
- 5
Joins
Inner, left, and anti-joins. Finding 'customers with no orders' and 'payments with no order'.
- 6
Duplicates and data quality
Why your join doubled the revenue, and how to detect it before anyone else does.
- 7
Subqueries and CTEs
Breaking a hard question into steps that each read like a sentence.
- 8
Window functions
ROW_NUMBER, LAG, running totals, and per-entity counts over time.
- 9
Case, coalesce, and cleaning in SQL
Bucketing, defaulting, and standardising categories in the query itself.
- 10
Performance basics
Why a query is slow, what an index does, and the habits that keep the warehouse bill down.
- 11
Views and sharing
Saving logic once, documenting it, and scheduling a report from it.
- 12
Capstone: a monthly business review from raw tables
Revenue, refunds, retention, and top customers, built as reusable views.
Free chapter 1 of 12
Tables, rows, keys
A database is a set of tables, and a table is nothing more than a spreadsheet with rules. Every row is one thing: one order, one customer, one payment. Every column is one fact about that thing. The rules are what make SQL possible: each row has an id that never changes, and other tables refer to that id instead of copying the data.
So an orders table does not store the customer's name. It stores a customer_id, and the customers table stores the name once. When the customer changes their name, one row changes, not thousands. This is why you will spend most of your SQL life joining tables together: the data is deliberately spread out.
Before writing any query, find three things: which table holds the thing you are counting, which column identifies each row uniquely, and which columns point at other tables. Ten minutes with SELECT * FROM orders LIMIT 20 answers all three. Skipping this step is where most wrong numbers come from: someone counts rows in a table where each order appears three times, once per item.
The sandbox in this course has five tables: customers, orders, order_items, payments, and refunds. They are modelled on a real Indian e-commerce business, with UPI and card payments, partial refunds, and the messy edges you will meet at work.
Who it is for
Analysts, operations and finance staff, and product managers who have warehouse or database access but depend on someone else to write the query.
Before you start
None. Spreadsheet comfort helps. No installation needed; the sandbox runs in your browser.
Taught by
Paul Montero
Founder and instructor
Questions about this course
How long do I have access?
Is the dataset included?
Can I get a refund?
incl. GST, 7-day refund