10 chapters are open
First lesson: Отчёт, который завис
Interactive course · SQL Performance
Your query takes 40 seconds.
Below decks you can see why.
Not "advanced SQL" but the engine room of a query: EXPLAIN ANALYZE, scans and indexes, the three JOIN algorithms, planner statistics, sorts spilling to disk. Every task runs on a ten-million-row database with a time budget and a live plan: not "get the right answer" but "fit into 500 milliseconds".
- live EXPLAIN ANALYZE in the lesson
- a 10,000,000-row database
- graded by the plan and the clock
EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE user_id = 4171
Seq Scan on orders (cost=0.00..214801)
rows=10 000 000 · Execution: 8 412 msThe same query, a different plan
The offer
Symptoms you have already seen
Six situations from work — and the diagnosis the course teaches. Each gets a chapter with live plans: not a retelling of the docs, but a walk-through on a base where slow is real.
Three scenes
What you see when you open the machine
Three mechanisms that decide a query’s fate — drawn rather than described: the route to the rows, three ways to dock two tables, and the memory bay a sort spills out of.
The route decides everything
The same WHERE can read the whole table — or forty rows out of ten million. The course teaches you to see the route in the plan and build the indexes it will take.
Three ways to dock
A JOIN is not one operation but three algorithms with different tempers. The planner chooses — based on your data — and the plan shows when it chose wrong.
Memory runs out silently
A sort that outgrows work_mem does not fail — it moves to disk and gets ten times slower. One line in the plan gives it away every time.
How it works
A course where the seconds are real
No platform has tasks like these — we checked: trainers grade the correctness of the answer, never its speed. Here the speed is the task.
Genuinely slow
The training base holds ten million rows, and a bad query genuinely keeps you waiting. An order-of-magnitude speedup is not a line in notes — it happens in front of you.
Graded by the plan, not the text
The platform reads your plan: did the Seq Scan go away, did the index kick in, did the time fit the budget. Copying will not pass — a copied query keeps the same slow plan.
You first — then the master
After you pass, the reference opens: its plan next to yours, node by node. You see not just "the right way" but exactly how yours differed — and by how many milliseconds.
Vault-9 · the lower decks
The station started answering slowly
The morning life-support report that used to assemble instantly took forty seconds today — and tomorrow will be worse: the archive has grown to ten million records. For the first time QUERY opens the hatch to the lower decks — where queries become routes through data. Down there stands the machine that decides which path every one of your queries takes. You will learn to read its blueprints — and to fix them.
- 01the report that took forty seconds
- 03a catalogue of a million cards
- 06the sort that outgrew its bay
- 07a star map three years stale
- 09the red zone: a 500 ms budget
The route
Five decks of the engine room
The program is built as a descent: first you learn to read the blueprint, then the catalogue and the machinery, then the map the machine routes by. And then — full speed.
The blueprint
How the machine reads a query — and where the plan burns
The catalogue
Indexes: how they work and why they stay silent
The machinery
Joins, sorts and the executor’s memory
The navigation room
Statistics: why the planner gets it wrong
Full speed
Production patterns, query surgery — and the red zone
The program
Ten chapters of the lower decks
The program is designed around the market’s gaps: we took apart course programs, books and job requirements — and built what nobody teaches. Chapters fill in waves, as BigQuery’s did.
The blueprint
2 chapters · 11 lessonsHow the machine reads a query — and where the plan burns
Forty seconds: your first EXPLAIN ANALYZE
You will see what happens to a query after Enter: parser, planner, executor. You will read your first plan, decode the cost numbers, find the node that eats all the time — and check the planner’s estimate against reality. The whole course stands on that skill.
Routes through the data: the four scans
You will take apart the four ways to reach rows: Seq Scan, Index Scan, Index Only Scan and Bitmap Scan — and when each wins. You will learn why a full pass is honestly faster on a small table, where Gather and workers come from in a plan — and why an Index Only Scan dies after mass UPDATEs.
The catalogue
2 chapters · 10 lessonsIndexes: how they work and why they stay silent
The index card catalogue
You will open up the B-tree and learn to design indexes: column order in a composite, covering INCLUDE, partial and expression indexes. And the honest price of each — the write penalty, bloat, and the indexes it is time to drop.
The index exists, the joy does not
The most common interview question: why is the index ignored. A function on the column, a quiet type cast, LIKE with a leading percent, OR — you will see each cause in the plan and fix it by hand. Plus GIN and pg_trgm where B-tree is helpless.
The machinery
2 chapters · 8 lessonsJoins, sorts and the executor’s memory
Three dockings: the JOIN algorithms
You will take apart the three JOIN algorithms — Nested Loop, Hash Join, Merge Join: why the planner picks each and how the plan shows it erred. Join cardinality, EXISTS instead of the DISTINCT "remedy", the NOT IN + NULL trap.
The working bay: memory and work_mem
You will learn where a query runs out of memory: work_mem is per operation, not per query, and whatever does not fit — sorts, hashes, bitmaps — spills to disk. You will learn to remove "Disk:" from the plan and get sorting from the index for free.
The navigation room
1 chapter · 5 lessonsStatistics: why the planner gets it wrong
A stale star map: planner statistics
You will descend to the statistics — the data about the data the machine routes by: estimate vs actual, ANALYZE after bulk loads, column correlation and CREATE STATISTICS, the ORDER BY + LIMIT trap, generic vs custom plans. No course teaches what this chapter holds.
Full speed
3 chapters · 15 lessonsProduction patterns, query surgery — and the red zone
A thousand small runs: N+1 and pagination
The application-side habits that kill databases most often: the ORM-made N+1 — a hundred and one logged queries become one; OFFSET pagination that reads everything scrolled past, and keyset pagination in its place; COUNT(*) under MVCC, and the price of wide rows — SELECT *, TOAST and JSONB.
Slow → fast
Query surgery: the correlated subquery that re-runs for every row, the CTE fence and MATERIALIZED, "the latest row per group" three ways, windows vs GROUP BY — with counterexamples both ways. The result must match; the plan must get better.
The red zone: the incident and the exam
The final incident: production sagged on a Friday — the evidence lives in pg_stat_statements, wait events and a stack of plans. The fork "slow or waiting": locks, which EXPLAIN will never show. Then a task marathon with time budgets and tightening constraints: first anything, then indexes only, then the query only. After you pass — the master’s debrief: the reference plan next to yours.
What you keep
More than chapters you have read
The diagnosis workflow
A step-by-step route: slow query → EXPLAIN ANALYZE → the node with the biggest time → estimate vs actual → the fix. The method job postings call "profiling skills".
The engineer's checklists
"Why is my index silent" — four causes with checks. "Pain signatures in a plan" — from external merge to a thousandfold est/actual gap. People keep these at hand for years.
The exam and the certificate
The red zone: a series of time-budgeted tasks on the shared ten-million-row base. The constraints tighten task by task. Pass — and take a personal engineer certificate.
The hatch is open. Come down.
The first chapter is open and free: a live EXPLAIN right inside the lesson, nothing to install. The next chapters ship in waves.
The average lesson takes 12 minutes