open atlas

databases

Databases

How databases store and find your data fast, keep it correct when many users write at once, and grow as the data gets bigger.

9 units·79 lessons·~48 h

Start track
00

Start from zero

Before the senior material: what a database even is, and the handful of words the rest of the track assumes you already know.
01

Relational model: tables, keys, constraints, when to bend the rules

Why Codd's 1970 relational model still wins on data integrity, what each normal form actually buys, where surrogate vs natural keys diverge, when JSONB and arrays beat a side table, and why some hyperscale shops disable foreign keys.
02

Indexes in PostgreSQL: B-tree, GIN, GiST, BRIN, and the cost of a wrong one

How Postgres indexes are built (B-tree, GIN, GiST, BRIN, SP-GiST, hash), why the leading-column rule is the most violated principle in production, how partial / expression / covering indexes change the cost model, and when to add or drop one.
03

Execution plans: how PostgreSQL finds and executes your query

How the PostgreSQL planner reads statistics to pick scans and joins, why row-estimate errors cascade into bad plan choices, and how to lock in a stable plan under traffic.
04

MVCC and isolation in PostgreSQL: snapshots, anomalies, bloat

How Postgres lets thousands of readers and writers share rows without blocking — and why one long transaction can grow a table by 100 GB.
05

Connection pooling in PostgreSQL: PgBouncer modes, sizing math, and pool-exhaustion failure modes

Why Postgres backends are heavyweight, how PgBouncer's session/transaction/statement modes change app contracts, the math behind pool sizing, the prepared-statement transaction-mode trap (and PgBouncer 1.21+ fix), and the Supavisor/Odyssey/PgCat landscape.
06

Schema migrations in PostgreSQL: locks, expand-contract, and the lock-queue failure mode

Why ALTER TABLE behind a long-running query freezes the database, how to decompose every breaking change into safe expand-contract phases, and what nine migration failure modes look like in production.
07

Sharding PostgreSQL: shard keys, hot-shard failure mode, partitioning vs Citus

When one Postgres is not enough — shard-key selection, hash/range/list/directory strategies, declarative partitioning vs Citus, co-location, the hot-shard failure mode, online resharding, schema-based sharding.
08

Putting it all together

One product grows from a 1-table MVP to a 1-billion-row Citus cluster through seven moments of database failure — schema, indexes, statistics, bloat, pooling, migrations, sharding — each one named, ordered, and triage-ready.

Build with this track

Guided projects that exercise what you learn here.

◆ Projects

Grounded RAG Service

A RAG demo that answers from a corpus is easy; a RAG service you'd trust in front of users is not. The hard part isn't retrieval, it's grounding: making the model say only what the retrieved text supports, attaching citations the reader can check, and proving with an eval set that the answers don't drift into confident fiction. You'll build the whole loop — chunk, embed, store, retrieve top-k, ground, cite, score — and feel exactly where it leaks.

◆ Projects

Idempotent ETL Pipeline

Pipelines don't fail gracefully — they fail at 3 a.m., halfway through a load, and someone re-runs them. This project teaches the one property that separates a hobby script from production data engineering: a run you can repeat any number of times and still land exactly one copy of each row. You'll build batch ingestion, an idempotent load, a watermark for incremental pulls, and the data-quality gates that stop bad data before it poisons everything downstream.

◆ Projects

Job scheduler

A cron + backoff job runner with at-least-once delivery, idempotent handlers, and visibility timeouts — so no job is silently lost even when workers crash mid-execution.

◆ Projects

Mini CRUD API

Build your first real backend: a tiny HTTP API that creates, reads, updates, and deletes notes — backed by SQLite so the data survives a restart. You go from a one-line 'hello' server to a small service that validates input and stores rows, one honest step at a time.

◆ Projects

Query plan visualizer

Paste an EXPLAIN (ANALYZE, FORMAT JSON) and render the plan tree with per-node timing and row-estimate error, so a bad join jumps out visually.

◆ Projects

Reporting Schema Optimizer

Reporting is where a database earns or loses its keep: the queries are wide, the tables are big, and 'it's slow' is the most common bug in production analytics. You'll model a sales-and-events domain, write the honest slow versions of the dashboard queries, then make them fast with indexes and materialized views — and you'll read EXPLAIN ANALYZE to prove the speedup instead of guessing at it. This is the heart of the track: turning a vague 'the report is laggy' into a measured, defensible plan change.

◆ Projects

Skip list

Build a probabilistic ordered data structure that delivers O(log n) search, insert, and delete without the rotation bookkeeping of balanced trees — just layered express lanes through a sorted linked list.

◆ Projects

URL shortener at scale

Build a URL shortener that survives real traffic — then run it: deploy it, watch it, and work the incident when one hot link melts your cache.

◆ Projects

Crash-safe key-value store with a WAL

Build a tiny on-disk KV store that survives a kill -9 mid-write by appending to a write-ahead log before touching the main file.

Next track

Caching

How to make apps fast by remembering results instead of recomputing them — and the hard part: knowing when that remembered copy is stale.