Database Concepts & Theory

RDBMS → NoSQL → Distributed SQL → Vector — why today's storage landscape has this many moving parts.

Tables, rows, columns, and schemas — the mental model every other chapter in this journey builds on.

1NF through 3NF, and why your data ends up split across multiple tables in the first place.

How a schema enforces its own correctness — and how foreign keys link the tables normalization just split apart.

Every SQL statement belongs to one of five sub-languages — knowing which clarifies what it actually does to the system.

SELECT, WHERE, GROUP BY, ORDER BY, and subqueries — the core query vocabulary every storage system eventually speaks.

INNER, LEFT, RIGHT, FULL OUTER, CROSS, and SELF joins — reassembling the tables normalization split apart.

Reusable, server-side SQL logic — and the real trade-off of putting logic in the database versus the application.

A saved query that runs live, versus a saved query that's precomputed and refreshed on a schedule.

Why an index makes a query faster, in plain terms — now that you've written enough queries to feel one run slowly.

The four guarantees a relational transaction makes about what happens when things go wrong partway through.

The consistency model most NoSQL and distributed systems choose instead of ACID — and why that's a deliberate trade, not a lesser one.

How Postgres-style engines let reads and writes happen at the same time without ever blocking each other.

How strictly a database stops one transaction from seeing another's in-progress changes — and the anomaly each level still allows.

The balanced, disk-page-based structure Postgres, InnoDB, and SQLite use to keep both lookups and range scans fast.

The append-only storage engine design behind Cassandra and RocksDB — built for write throughput a B+ Tree can't match.

The crash-recovery mechanism nearly every database relies on — whether it's built on a B+ Tree or an LSM Tree underneath.

The standard toolkit for scaling a relational database further — connection pooling, read replicas, and sharding, roughly in that order.

How to find out why a query is actually slow, instead of guessing from how the SQL looks.

Two different NoSQL data models, both built for scale — flexible nested documents versus partition-key-distributed rows.

A single-threaded, in-memory data structure store, fast enough to answer in microseconds — with a real durability trade-off underneath.

The data structure behind full-text search — mapping words to documents, the exact opposite direction a normal index goes.

How Spanner and CockroachDB combine sharding, consensus, and distributed transactions to deliver global ACID over SQL.

A backup you've never restored isn't a backup — it's an unverified assumption about what your data looked like at some point in the past.