8 chapters are open
First lesson: You Have the Answer, but What Did It Cost? Measuring Without a Stopwatch
Interactive course · ClickHouse
Two queries, one answer.
Two different prices.
Not "an overview of a fast analytical database" but one reading-room desk you assemble yourself: aggregate combinators, arrays as columns, funnels and retention, time without gaps, joins with their failures — and the layout that makes the very same answer twice as cheap. A real ClickHouse 24.10 in the sandbox, zero installation.
- A real server, not syntax highlighting
- Zero installation: no client, no Docker, no card
- The whole first chapter is free — 5 lessons
- A delta on SQL: not a paragraph on SELECT or GROUP BY
What hurts
A symptom from work — and what the course does about it
On the left, what people arrive with. On the right, the method from the program that closes it — and the lesson where it runs in a cell.
A query "got slow", and nobody can say why: the stopwatch shows something different every time on the same data
the price of an answer, in what it readSeconds are the wrong instrument here; what was READ is the right one: parts, rows and marks come out of the execution plan. From the first lesson the course measures answers with those, so every later claim rests on a number rather than a feeling.
Five metrics, five separate scans of the very same table
the condition inside the aggregatecountIf, sumIf, uniqIf and the rest of the suffix combinators: five answers in one pass over the column instead of five queries. Not syntactic sugar — in a columnar engine every extra pass is paid for in reads.
Two reports count "unique users" and disagree
accuracy stated as a numberThere are five answers to "how many distinct", each with its own error and its own price. Plus the rule that stops you adding ready-made daily numbers into a monthly one — the most common reason a month does not tie out.
A funnel written as five joins that takes a minute to run
the visitor’s path in one passwindowFunnel, sequenceMatch and retention answer "did they get there", "in what order" and "did they come back" in a single pass over a column. And in the same lesson: where each of them lies — a window catching someone else’s step, a pattern matching in the wrong place.
A day vanished from the daily chart because nothing happened that day
a series with no gapsA grid of intervals of any length, WITH FILL with INTERPOLATE, the totals row and the trap it carries, window functions under ClickHouse names. A hole in a series is not a property of the data but a decision in the query.
A join against a big table dies on memory
the right side and its algorithmThe right side goes into memory whole — that is the design, not a bug. Hence choosing join_algorithm by its size, a zero instead of NULL for an unmatched pair, and a lookup that is cheaper kept as something other than a table.
This course is for you if
- An analyst handed a ClickHouse connection and told to "write it like Postgres" — except it does not behave like Postgres
- Anyone confident with SELECT, GROUP BY, JOINs and window functions: this course starts where our SQL course ends
- Anyone reading job ads and seeing ClickHouse required of analysts, not only of engineers
- Anyone who finished the data-engineering course: there ClickHouse is the end of a pipeline, here it is the workplace of the person answering the questions
And NOT for you if
- A beginner without SQL. There is not one paragraph on SELECT, GROUP BY or window functions — that is the neighbouring course, and this one starts where it ends
- Anyone looking for an administrator’s course: replication, server tuning and cluster operations are not here, and that is stated in a section of its own below
- Anyone expecting a "ten databases in a month" survey. This course is about ONE engine and about how it differs from a row store
- Anyone who needs a diploma and a job placement. The course gives you the skill, a finished answer and a platform certificate — not a guaranteed offer
How it works
A lesson is closed by the server, not by scrolling
Every lesson has an executable ClickHouse cell and every lesson has a check. An answer counts by the rows it returned, not by the letters it was written with.
A live cell
The query goes to a real ClickHouse 24.10. Every run gets its own temporary database and drops it afterwards, so nobody else’s experiment leaks into yours.
Engine failures as teaching material
Thirteen lessons are built on a real failure: memory blown by the right side of a join, a query refused for missing the sorting key, a result-size limit. You see the text the engine returns to your cell and fix the cause.
A gate made of tasks
Every chapter closes with trainer tasks available ONLY on ClickHouse: you cannot pass them in Postgres, otherwise the gate would test something other than what it taught.
The sixth shift of one story
27 March 2184, 10:15. You are on this side of the glass.
The Vault-9 archive station, the Academy reading room. The night pipeline runs without you: the data arrives, a re-run breaks nothing. The room asks different questions — how many, who, in what order, did they get to the end, did they come back a week later. The curator wants three numbers for March, and two of your queries return the same answer at different prices.
The mentor is the same — QUERY, the old archive intelligence with the temper of a cat who walked you through the first signal. For every new answer he has exactly one question: how much did you read to be able to say that. He does not accept an answer without a number. By the last chapter you find that nearly everything you took for a property of the query — fast, cheap, no duplicates — was a layout decision someone made before you.
The route
Four layers of one answer
The course is not a list of engine features. Every chapter puts one more answer on the room’s desk, and every answer runs in a cell.
- I
The dialect of an answer
What an answer is measured in, and how to state its accuracy as a number
- ch1The reading room: what an answer is measured in
- ch2How many distinct, and how exact
- II
The shape of an answer
Lists, a visitor’s path and time — what the room’s answers are made of
- ch3Arrays: a list as a column
- ch4The visitor’s path: funnel, pattern, retention
- ch5Time: the grid, a series with no gaps, the window
- III
The price of an answer
Layout and joins: why one answer costs more than another
- ch6Layout: why one answer costs more than another
- ch7Joins: why they work differently here
- IV
The answer, handed over
The capstone, more than one machine, and an exam on a question you have not seen
- ch8Assemble the whole desk and defend it with numbers
The program
8 chapters, 41 lessons, 13.1 hours
The contents are approved and match the canon — a test enforces that, not a promise. A chapter whose lessons are already in the database expands into links and progress; the rest are waiting for their wave.
The reading room: what an answer is measured in
Your first shift on this side of the glass: the curator wants three numbers for March, and two queries return the same answer at different prices. There is no clock in the room — a stopwatch would count the database being created and seeded — so an answer is measured in what it read: parts, rows, marks. By the end of the chapter you have the first answer on the room’s panel and can prove with a number that the neighbouring one costs more.
How many distinct, and how exact
Two of the room’s reports contradict each other, and both are right. "How many distinct" is five different numbers, each with its own error and its own price; "what is the median" is three. Plus the rule that stops you adding ready-made daily numbers into a monthly one — and the one reason a mart stores a state instead of a number.
Arrays: a list as a column
A list here is an ordinary column, not a serialised string you later pick apart with a regex. Build it, unfold it back, compute over it with a lambda, test membership, and hand it back as the answer. Half the reports that needed a join in a row store need none here — and read less.
The visitor’s path: funnel, pattern, retention
The room’s behavioural questions — "did they get there", "in what order", "did they come back a week later" — are answered in a single pass over a column, not with five joins stacked on each other. The chapter sets up windowFunnel, sequenceMatch and retention and shows honestly where each of them lies: a window that catches someone else’s step, a pattern that matched in the wrong place.
Time: the grid, a series with no gaps, the window
Every question in the room is about time, and this chapter covers what no other course on the platform does: a grid of intervals of any length, a series where a missing day does not disappear but shows as a zero, a totals row with the trap it carries, and ClickHouse window functions under their own names.
Layout: why one answer costs more than another
For the first time you touch not the query but the room’s mart itself. Reading the plan, taking the engine’s verdict instead of the weather, choosing the column order of the sorting key for one specific question, and four ways to read less — PREWHERE, a skip index, a projection, a second key — with a decision tree and the price of each. By the end you can not only fix someone else’s query but lay the table out so the query passes under the hand-over switch.
Joins: why they work differently here
A join here is not the join you know from a row store: the right side goes into memory whole and hits its limit, an unmatched pair yields a zero instead of NULL, and a small lookup is cheaper kept as something other than a table. Every claim in the chapter is proved by an engine error and fixed by a setting or a rewrite.
Assemble the whole desk and defend it with numbers
A capstone in two passes: assemble the room’s answers for a fixed list of questions, then prove from the plan’s numbers that they are cheap. Then an answer assembled from two machines, and an honest boundary: what the sandbox does not have, what we substituted for it, and what opens up on your first day at work. It ends with an exam on a question you have not seen.
The honest boundary
What is not in the course, and why
You should learn the edge of your skill before a recruiter finds it for you. So it is stated here, before you buy, and repeated in the course’s last chapter.
Administration and replication
The platform sandbox runs as an unprivileged role: the engine’s system tables are closed and maintenance commands are refused. Otherwise it would stop being a sandbox.
Everything usually inspected through system tables is shown here by permitted means, and the course says plainly what it substituted. A lesson that talks about something the sandbox lacks must carry a notice — its presence is enforced by a gate, not by the author’s conscience.
A genuinely distributed setup
The sandbox is a single server. Promising a distributed cluster would mean selling slides as practice.
A dedicated lesson assembles an answer from two local tables with UNION ALL and uses it to show the key consequence of distribution: why distinct counts cannot be added across nodes while sums can.
Ingestion and streaming
That is the neighbouring course’s subject — there ClickHouse sits at the end of a pipeline and you learn to write into it so the data can be reloaded.
Here the data is already there and the question is different: how to ANSWER from it, and what that answer costs. The absence of topic overlap was verified by an exhaustive search across every course’s canon.
FAQ
Frequently asked
No. ClickHouse 24.10 runs as the platform sandbox right in your tab: a lesson cell is executed by a real server, not highlighted as text. No Docker, no client, no cloud account, no credit card — open a tab and start writing.
The shift starts at 10:15
The first chapter is open in full — 5 lessons, no subscription and no card. You decide after that.