Stop guessing which index to add. The planner already tells you what it's doing — in both engines — once you can read what it prints.
Someone says the database is slow, and the usual response is to add an index to whatever column is in the WHERE clause and hope. This course replaces that with a procedure. You start by finding which query is guilty — the slowest one is almost never the one worth fixing, and the query burning 38% of your database often takes half a millisecond. Then you learn to read a plan: it executes bottom-up while it prints top-down, the times are cumulative, and the most diagnostic number is the ratio between the planner's estimate and what actually happened. Every concept is taught in PostgreSQL and MongoDB side by side against one dataset, because the physics is the same and only the output differs. Join algorithms and the nested-loop catastrophe that turns a good plan into a six-hour query when one estimate is wrong by a thousandfold. Statistics, where the independence assumption between columns causes more bad plans than anything else. Then the slow queries with no fix at the query layer: a working set that outgrew cache, forty sessions queued behind one idle transaction, schema shape designed from the read paths backwards. One docker compose file, five million rows, no cloud account.
Built by Lakshya Kumar
Paste this into any AI chat. Fill in the bracketed parts with your context — you'll get back a straight answer on whether this belongs on your plate.
We grant free access case-by-case — students, career-switchers, builders on a tight budget. Sign in to send us a note.
Sign in to applyFinished the tasks? Take the prompt to your AI and get tested on it. We copy the prompt and open the app — just paste it in.
One shows you what the planner intends, the other what the engine did. The gap between them is where nearly every slow query hides.
Six ways to get rows off a table, each optimal somewhere. Knowing which one you want is how you know what to build.
Three algorithms, each unbeatable in its own corner. The planner picks one from a row estimate, and a wrong estimate is catastrophic.
Same three columns, six possible orders, and only one of them serves the query you have. The rule that picks it is short.
A B-tree cannot index inside a JSON document, a text search, or an array. Six other structures can, each with one job.
Every plan decision comes from a row estimate, and every row estimate comes from a sample. Here is what is in the sample and what it misses.
Same plan, same rows, ten times the latency. The plan was never the problem — the pages stopped being in memory.
A query that takes two milliseconds alone can take four seconds under load. Nothing in its plan changed — it is waiting.
Some queries cannot be made fast. The row is too wide, the table too tall, or the data is in the wrong place entirely.
I'm taking "Fix the Slow Query: EXPLAIN ANALYZE in Postgres and Mongo" — a database query performance course in the engineering track. Ten modules: finding which query is actually guilty, reading a plan, scan types, join algorithms, index key order, index types beyond the B-tree, statistics and estimates, buffers and I/O, transactions and locks, and schema shape. My context: 1. Which engine(s) I use: [PostgreSQL / MongoDB / both / something else] 2. Roughly how large: [rows or documents in the biggest table, total size on disk, RAM on the server] 3. What is instrumented today: [nothing / pg_stat_statements / the MongoDB profiler / an APM / full telemetry] 4. The shape of the workload: [mostly reads / write-heavy / analytics / a mix — and roughly what ratio] 5. The slowest thing users complain about: [describe] 6. What I have already tried: [describe, including anything that did not help] Given that, answer: - Which module should I start with, given what is already instrumented? Skipping ahead is fine if the earlier ground is covered. - Which parts of this course do NOT apply to my situation, and why? - For the thing users complain about, which of the seven layers is it most likely to be — index, statistics, memory, infrastructure, application call count, concurrency, or requirement — and what single measurement would tell me? - What is the cheapest change that would most improve my ability to diagnose the next one?
The chapter this course expands on. Statistics, planner control, and bulk loading.