A database is the piece of infrastructure most engineers trust the most and understand the least. The interface is a string of SQL and the implementation is a hundred decisions nobody sees: how a row is placed inside an eight kilobyte page, which page gets evicted when the pool is full, how a tree keeps itself balanced while twelve threads descend it, what exactly is on disk at the instant the power is cut, which of two transactions is allowed to proceed, and why the planner chose a sequential scan over the index you built for it. This course is those hundred decisions, in the order an engine builder would meet them.

The spine is a build order. It starts with the anatomy of an engine and the layers a query passes through, then goes straight to the page: the slotted page layout, tuple headers, variable-length storage and the overflow mechanism for a value that does not fit. Then the buffer pool, which is where almost all database performance is decided, with its page table, its pinning rules, its replacement policy and the write-back path that connects it to durability. From there the storage structures, taken as two families rather than one canonical answer: B-trees with their split and merge mechanics and the latching protocols that let them be concurrent, LSM trees with the compaction strategies and the amplification arithmetic that chooses between them.

Durability comes next, because it constrains everything above it. Write-ahead logging with log sequence numbers and the no-steal and no-force rules, checkpoints and the three-phase ARIES recovery that follows a crash, and then the physical reality underneath: what fsync does and does not guarantee, how a torn page happens, and the double write buffer and checksums that detect or prevent it.

Concurrency control is treated as a precise subject with precise definitions. The isolation levels as the anomalies they permit rather than as names, two-phase locking with the lock manager that implements it and the deadlock detection that cleans up after it, multiversion concurrency control with tuple visibility rules and the garbage that versions leave behind, and serializable snapshot isolation as the technique that made true serializability affordable.

Query processing is the half of an engine most engineers never see at all. The parser, the binder and the rewriter, the statistics and cost model that produce an estimate, why that estimate is usually wrong and what it does to plan quality, the three join algorithms with the arithmetic that chooses between them, join ordering as a search problem, and the execution models from the Volcano iterator to vectorized batches and compilation. Then access paths as the planner sees them: covering indexes and index-only scans, hash and bitmap and specialized indexes, and partitioning as the engine implements it rather than as a configuration option.

The last third leaves the single node. Physical and logical replication with the trade-offs each one makes, two-phase commit with every one of its failure modes written out, consensus-backed storage as the modern answer to those failure modes, and distributed query execution with the shuffle that dominates its cost. The course closes with four engine tours: Postgres with the heap and vacuum and transaction id wraparound, InnoDB with its clustered index and undo logs, SQLite as a complete engine small enough to read, and RocksDB as a storage library other systems are built on.

Every lesson names the configuration parameters it discusses with their defaults, works the arithmetic with real numbers, and prefers the failure case to the happy path. There are twenty judged coding problems, because this subject is the one where the implementation can actually be written: a B-tree insert with splits, an LSM merge, buffer pool eviction, WAL redo, MVCC visibility, lock compatibility, cost estimation and join selection among them. By the end you will be able to read an execution plan and say what the engine will do physically, explain what survives a power cut and why, choose a storage structure from the read and write mix rather than from habit, and follow a transaction from parse to commit record.