Databases, without the fluff

How a database finds rows without scanning every one — B-tree structure, composite and covering indexes, and the write cost you pay for every read you speed up.

Indexes aren't free wins — each one slows writes and can be silently ignored by the planner. Knowing when an index won't be used is rarer, and worth more, than knowing how to add one.

The guarantees that keep concurrent operations from corrupting each other — atomicity, consistency, isolation, durability — and what "all or nothing" actually costs.

Everyone can expand the acronym. The signal is knowing which letter you're actually leaning on when you wrap two writes in a transaction — and that the "I" is the one that breaks in ways you'll never catch in single-threaded testing.

The dial between correctness and throughput — read committed, repeatable read, serializable, and the anomalies each one still lets through: dirty reads, non-repeatable reads, phantoms.

Most production databases don't run at the isolation level people assume. Knowing your default is probably Read Committed — and exactly which race conditions that quietly permits — is the gap between a bug you prevent and one you debug at 3am.

What the planner does with your SQL — scan versus seek, join strategies, and how to read an execution plan to find where the time actually goes.

This is what turns "the query is slow" from a guess into a diagnosis. An EXPLAIN plan is the closest thing databases have to a debugger, and most people never learn to read one.

The plumbing that keeps your app off the database's back — reusing connections instead of reopening them, and serving hot reads from a cache instead of a round-trip. Pool sizing, cache-aside and read-through, TTLs and invalidation.

Both are defenses that become the outage. An exhausted pool queues every request until it times out — the database is fine, but the app looks dead. A cache whose keys all expire at once stampedes the very database it was shielding. What you added to prevent failure becomes the failure.

Copying data across machines for availability and read scale — leader-follower topologies, synchronous versus asynchronous replication, and the lag that rides along.

Replication lag is the bug that only shows up under load: you write, you immediately read, and you get stale data because the read hit a follower that hadn't caught up yet. Knowing that failure mode exists is most of preventing it.

Splitting one dataset across many machines to scale past a single node — partition keys, and why the wrong key is so painful to undo.

Anyone can shard. The expensive lesson is that the query which fans out across every shard — the one your partition key didn't anticipate — costs more than never sharding at all. Picking the key is the whole game.

Relational, document, key-value, wide-column — and the CAP tradeoffs that push you toward one. When a schema is an asset and when it's a cage.

The scale you gain from NoSQL is usually paid for in the joins and transactions you no longer get. The real question was never which is better — it's whether your access pattern can actually live without them.