Databases — How They Actually Work
You can already write a join, add an index, and wrap two statements in a transaction. So why does the report endpoint die on the 30th, why does a read sometimes not show the write you just made, and why does “just add a cache” turn into a 2am incident? Those answers don’t live in the SQL — they live in the engine under the SQL. This track opens that engine up.
The Goal
By the end of this track you can:
- Separate the two skills most people blur together: writing queries vs. understanding the machine that runs them
- Explain how a database physically stores rows, finds them, and survives a power cut
- Choose between relational and NoSQL on evidence, not vibes — and know when reaching for NoSQL is a mistake
- Reason about replication, sharding, and caching as the real tools companies use to scale
- Walk into a SQL or database-systems interview round with answers built on mental models, not memorized definitions
SQL track vs. this track — the one distinction that matters
You already finished the SQL track. Keep it close; this track sits directly underneath it.
| The SQL track taught you | This track teaches you |
|---|---|
| How to query — joins, group by, window functions | How the engine runs those queries on disk and in memory |
| How to use an index | What a B-tree physically is, and why the planner sometimes ignores it |
| How to write a transaction | How WAL, the buffer pool, and durability make that transaction safe |
| One database (PostgreSQL), one schema | When a different kind of database is the right call |
Put bluntly: the SQL track makes you productive. This track makes you the person in the room who can explain why — which is exactly the line between a junior who copies queries and an engineer companies pay for.
The modules
Read them in order. Each builds the mental model the next one assumes.
| # | Module | What clicks |
|---|---|---|
| 01 | How Data Is Stored & Found | Pages on disk, heap vs index, B-tree internals, WAL, the buffer pool, why sequential beats random |
| 02 | Relational vs NoSQL | The five database families, ACID vs BASE, when NoSQL genuinely wins, and the default-NoSQL trap |
| 03 | Replication, Sharding & Scaling | Primary/replica, read scaling, replication lag, sharding by partition key, CAP made concrete |
| 04 | Caching & Consistency | Cache-aside vs write-through, TTL, the two hard problems, where caching bit a real system |
| 05 | SQL & Database Interview Practice | 15–20 real interview questions across SQL and database systems, with model answers |
When the engine breaks — the real-error companions
Two docs in this folder aren’t lessons — they’re field notes from problems that actually happened. Read them when you hit the same wall, or now, to see what the abstract concepts look like as a 2am error message:
- DB Migrations — Basics to Full — how schema changes ship safely. Module 01 explains why a column add can lock a table; this doc is the playbook for doing it without downtime.
- RDS Import: SUPER / SYSTEM_VARIABLES_ADMIN Denied — what happens when a managed cloud database (module 03 territory) refuses a privilege your local one always granted. The price of someone else running your database.
These stay as you grow — every real error you hit on a database becomes a new note like these.
Start here
Open Databases 01 — How Data Is Stored & Found. Have psql ready and your SplitEase schema loaded — the very first thing you’ll do is peek at where a row physically lives on disk. Everything in this track is more fun when you can poke the machine and watch it react.
Check Yourself
If you can answer these in your own words, you know what this track is for and what it will hand you. If one is fuzzy, that is fine — it is the module that will fix it.
What is the one distinction this track draws between itself and the SQL track?
The SQL track taught you to query — joins, group by, indexes, transactions. This track teaches you the engine that runs those queries: how rows sit on disk, how indexes are physically built, and how a transaction is made safe.
Why does a read sometimes not show a write you just made?
Because the read can land on a replica that has not yet caught up to the primary. That gap is replication lag — covered in module 03, not a bug in your query.
What three engine pieces make a committed transaction durable?
The write-ahead log (WAL), the buffer pool, and the durability guarantee that ties them together — the change hits the sequential log on disk before commit returns. Module 01 builds this mental model.
What is the "default-NoSQL trap" this track warns about?
Reaching for NoSQL before you have evidence you need it — trading away ACID guarantees and relational structure you actually wanted. Module 02 teaches choosing the database family on evidence, not vibes.
Which module covers replication, sharding, and CAP — and what real pain does it explain?
Module 03 (Replication, Sharding & Scaling). It makes replication lag, read scaling, sharding by partition key, and CAP concrete instead of abstract.
Why are the two real-error docs in this folder not numbered as modules?
Because they are field notes from problems that actually happened — the migrations playbook and the RDS privilege denial — not lessons. They show what the abstract concepts look like as a 2am error message.
What is the very first hands-on thing module 01 has you do?
Peek at where a row physically lives on disk in your SplitEase schema, using psql — poking the machine and watching it react.
In one line: what does this track make you, that the SQL track does not?
The person in the room who can explain why a query behaves the way it does — the line between a junior who copies queries and an engineer companies pay for.
This track has no tracker footer of its own — each module logs itself when you finish it.