One Size Fits None: The Database Landscape

In Capstone Pass 1 you sketched the delivery marketplace: an API, a load balancer, a cache, a queue — and one database holding everything. That database is about to become the most interesting box in the diagram.

Look at what the app actually asks it in a single minute of lunch rush. Checkout wants to decrement inventory, charge a card, and create an order — three writes that must succeed or fail together. The cart wants one value for one user key, in about a millisecond, ten thousand times a minute. The home screen wants every restaurant within two kilometers, sorted by distance. The search bar wants dishes relevant to "spicy ramen" — not rows that merely contain those letters. Every courier phone is appending a GPS ping five times a second, and the ops dashboard wants those pings aggregated into five-minute windows. And the recommendation panel wants dishes similar to what you just ordered — where "similar" means their embeddings are close: an embedding is a list of numbers a model assigns to a thing so that similar things land near each other, and "find me more like this" becomes a distance calculation.

Six questions. Six completely different shapes. One engine answering all of them — for now.

In this lesson: why the database world split into eight families, what actually forces the split (it isn't fashion), a map of every family and the one question each answers fastest, and the judgment call that follows — including why the answer is not "run eight databases."

Scope: each family gets its own lesson right after this one — internals live there, not here. The full decision checklist is SQL vs NoSQL: The Decision Rubric, and how row-versus-column layout serves transactions versus analytics is OLTP vs OLAP. This lesson is the map, not the street view.

For about twenty-five years, the industry's answer to every data problem was the same: a relational database. One architecture — row storage, B-tree indexes, SQL, transactions — originally tuned for business record-keeping, stretched over everything from telescope data to shopping carts. It mostly worked, because most data really was business records, and hardware kept getting faster.

In 2005, Michael Stonebraker — one of the architects of that very tradition — published a paper with a title that read like a resignation letter: "One Size Fits All": An Idea Whose Time Has Come and Gone. His argument was physical, not stylistic. A text-search engine, a stream processor, and a data warehouse each want such different storage layouts and execution paths that bolting them onto one engine means being mediocre at all of them. He predicted the market would "fracture into a collection of independent database engines."

He was right. As of July 2026, db-engines.com tracks 434 different database systems. The fracture happened; the eight families in this section are its stable continents.

He was also — in a way that took twenty years to see — half wrong. Hold that thought until The Twist below; it changes what "choosing a database" means in 2026.

It's tempting to think 434 engines exist because programmers like building databases (they do) or because vendors like selling them (they really do). But the fracture has a mechanical cause, and you already own both halves of it from Fundamentals of System Design.

Half one: an engine's layout is frozen physics. You saw in Sequential vs Random Access: Why Order Matters that reading data in the order it's stored is orders of magnitude cheaper than seeking around — and in The Memory Hierarchy that every layer rewards you for asking for nearby things. A storage engine has to commit to ONE physical arrangement: rows packed together, columns packed together, an append-only log, a sorted tree, an inverted index from words to documents, a graph of pointers, a lattice of vectors. Each arrangement makes one access pattern nearly free — and quietly taxes every other.

Half two: workloads have shapes. "The value for this key" touches one location. "Orders that must all commit or all abort" touches a few locations atomically. "Restaurants near me" is a two-dimensional range. "Relevant to 'spicy ramen'" inverts the question — it starts from words and asks which documents. "GPS pings, five-minute windows" is an append firehose read back in time order. "Similar to this dish" is nearest-neighbor distance in a 1,000-dimensional space. No layout serves all of these natively, for the same reason no single building is a great warehouse, library, and race track.

Put the halves together and you get the sentence this whole section hangs on: a database family is a bet, frozen into the engine's layout, on which question you'll ask most. Pick the engine whose bet matches your loudest question and everything feels effortless. Mismatch them and you'll spend your career writing workarounds — or waiting.

That's also why the families aren't going to merge back into one perfect engine: the bets conflict. Optimizing for append-heavy time windows means not optimizing for in-place multi-row updates. This isn't a temporary gap in engineering; it's geometry.

Here is the whole landscape, one card per family: the question it answers fastest, the bet its layout makes, one production system that proves it at scale — and the lesson where you'll open it up.

Relational — "keep many kinds of records correct, and query them any way." The bet: rows in tables, B-tree indexes, and transactions that make concurrent writers safe. It's the only family whose native question is correctness — which is why it's the default, and why on Prime Day 2025 Amazon Aurora quietly processed 500 billion transactions. Full story in Relational Databases: The Default for a Reason.

Key-value — "the value for this key. Now." The bet: give up rich queries entirely; a giant dictionary can answer lookups in microseconds and shard across the planet by key. On Prime Day 2025, DynamoDB peaked at 151 million requests per second with single-digit-millisecond responses. The whole family in Key-Value Stores.

Document — "this whole aggregate, shaped like my code." The bet: store the order with its items inside it, as one JSON document — one read fetches what the app calls one thing. No translation layer between objects and tables. Details in Document Databases.

Wide-column — "write-heavy rows clustered by key, petabyte-wide." The bet: partition rows across many machines by key, sort within the partition, optimize for relentless writes. Discord stores trillions of messages this way — and their p99 reads dropped from 40–125 ms to 15 ms when they moved clusters from 177 Cassandra nodes to 72 ScyllaDB nodes. The layout in Wide-Column Databases.

Graph — "hop the relationships, N levels deep." The bet: store edges as pointers so traversal never pays for joins. LinkedIn's LIquid serves "people you may know" from 270 billion edges at ~2 million queries per second. When this bet earns its keep — and when it doesn't — in Graph Databases.

Time-series — "append now; scan a window of time later." The bet: time is the primary key; compress aggressively, age data out automatically. Netflix's Atlas sustains over 1.2 billion live time series to answer "what happened in the last five minutes" during a failover. Mechanics in Time-Series Databases.

Full-text search — "which documents are RELEVANT to these words?" The bet: invert everything — map each word to the documents containing it, then rank the matches. It's why search at Wikipedia, GitHub, Netflix, and Uber runs on Elasticsearch rather than on LIKE '%ramen%'. The teaser is Full-Text Search Databases; the ranking math waits in Inverted Index + TF-IDF/BM25.

Vector — "what's most SIMILAR to this embedding?" The youngest family: store learned vectors, index them for approximate nearest-neighbor search, answer "more like this" in milliseconds. Whether this is truly a family or just an index every engine now carries — that argument is exactly where the landscape is moving, and it opens in Vector Databases.

Read the cards again and notice what they are: eight different questions, not eight brands. That's the map worth memorizing — engines change; the question shapes don't.

Enough telling. Below are the marketplace's six workloads as live lanes, and nine engines to power them with — the eight families plus the one every senior engineer will suggest first: Postgres with extensions (PostGIS for geo, full-text search, pgvector, Timescale).

Three experiments, in order. First: pick Postgres + extensions at 1× scale — six green lanes; the "just use Postgres" meme is simply true at launch scale, and you should feel why. Second: drag the scale to 100× and watch which lanes redline first — the extensions didn't break; the workloads outgrew one box. Try to find any single engine that keeps six lanes green up there. Third: switch to build your stack, give each lane the family whose question it asks — and read the bill at the bottom before you celebrate.

Now the thought you were holding. In 2024, Stonebraker returned with Andrew Pavlo to grade his own 2005 prediction (What Goes Around Comes Around... And Around), and the verdict is the most useful sentence in this lesson for anyone past the basics: the engines fractured, but the query models converged.

Every NoSQL family that arrived shouting that SQL was dead ended up speaking it. Document stores added SQL-style query layers one by one — the paper calls them "on a collision course with RDBMSs"; MongoDB, the last holdout, added SQL for its Atlas service. Meanwhile SQL absorbed the invaders' best ideas: JSON columns, then time-series extensions, then — within less than one year of ChatGPT making embeddings mainstream — native vector indexes in Oracle, ClickHouse, SingleStore, and Postgres via pgvector. Compare that to JSON support, which took relational vendors most of a decade. Even graphs: the SQL:2023 standard added property-graph queries, and DuckDB's implementation beats a leading native graph database by up to 10× on traversal benchmarks.

Production agrees with the paper. Facebook serves the largest social graph on Earth — over a billion reads per second — from TAO, a graph-shaped cache sitting on MySQL. Uber serves rides, Eats, and payments — tens of petabytes, tens of millions of requests per second — from Docstore, a document API built on MySQL with an LSM engine underneath. Look at the db-engines top 15 and nearly every entry, from Oracle to Redis, is tagged "multi-model."

So was 2005 wrong? No — the specialization was real, it just landed one level down. Columnar storage didn't stay a niche; it took over the entire analytics market (every warehouse vendor converted — that story pays off in OLTP vs OLAP). Search engines remain stubbornly separate products. Time-series engines keep winning their vertical. The architectures specialized even while the query languages converged.

Which means "family" in 2026 names something subtler than it did in 2010: an identity, not a wall. Postgres can store vectors; that doesn't make it Pinecone at a billion embeddings. MongoDB can run transactions; that doesn't make it the system of record for a bank. The question that matters when you pick an engine is no longer "can it do X?" — almost everything can — but "what was it BUILT to do, and what is my loudest question?"

Here's the trap hiding in this lesson's title. "One size fits none" sounds like an instruction to give every workload its own specialized engine. The widget just showed you the truth: assign each lane its perfect family and you get six green lanes — plus a bill.

The bill, itemized. Every engine you add is a new operational life: its own configuration, monitoring, backups, scaling behavior, failure modes, upgrade treadmill, and on-call expertise. Six engines is six runbooks. Your data now lives in several places that must be kept in sync — pipelines you'll build and babysit. And the sharpest line item: transactions stop at each store's edge. The moment checkout writes to one engine and inventory lives in another, "all-or-nothing" is no longer something the database gives you — it's something you have to engineer. That problem is hard enough to own three lessons in Transactions & Concurrency, starting at The Distributed Transaction Problem.

And the other side of the ledger is stronger than most engineers expect: the default stretches enormously far when you push it deliberately. Figma grew its Postgres fleet roughly 100× in four years — one big box, then read replicas and caching, then vertical partitioning, then a query proxy for horizontal sharding. Notion runs 480 logical shards across 32 physical Postgres instances. Neither reached for a new family until a measured workload forced it.

So the judgment this lesson equips — the one you'd defend in a design review: default boring, stretch deliberately, specialize on evidence. Start with the general-purpose engine (usually relational). Stretch it with an extension the moment a workload asks a foreign question quietly. Add a specialist only when a workload asks its question loudly — measured at the engine's physics, not its default settings — and you've priced the runbook you're adopting. Under interview follow-up, that last clause is the difference between "I read a blog post" and "I've paid this bill."

The six-question checklist for making that call precisely — workload shape, consistency needs, scale trajectory, team, ecosystem, exit cost — is two lessons ahead, in SQL vs NoSQL: The Decision Rubric.

A friend is building a fitness app and — having heard you're taking this course — asks you to sanity-check the data layer. Five workloads. For each, name the family whose native question it matches. Then answer the harder final question.

1. Accounts & subscriptions — users, plans, payments; billing must never double-charge.
2. Live workout session state — "current heart-rate zone for user 8412" — read/written every second, by key.
3. Workout history charts — every rep and heart-rate sample ever, plotted as "last 30 days, daily buckets."
4. Exercise library search — "dumbbell chest exercises for beginners," ranked by how well they match.
5. "Workouts like yours" — recommend sessions similar to your last one, from embeddings.

Final question: the app has 2,000 users. How many database engines should it run today?

Answers. (1) Relational — money is a correctness workload; that's the native question of exactly one family. (2) Key-value — one value by one key at high frequency; microsecond dictionary. (3) Time-series — append-only samples, windowed reads, automatic aging. (4) Full-text search — relevance ranking is an inverted-index question. (5) Vector — "similar to" is nearest-neighbor distance.

Final answer: one. At 2,000 users, every one of those workloads fits comfortably in a single Postgres with extensions (or a single multi-model document store) — you saw this exact truth at 1× in the widget. The families tell you where each workload will graduate to when its question gets loud. Writing that migration path down on day one — and not paying for it until the numbers demand it — is precisely the judgment this course is building.

• "NoSQL means no schema." There is always a schema — the only question is who enforces it. Relational engines check it on write; document stores make your application code check it on read. Flexible is real; absent is a myth.
• "NoSQL is faster than SQL." Faster at what? A family is fast at its native question and slow at foreign ones — you watched a key-value store serve carts in half a millisecond and fail checkout completely. Modern relational engines match or beat KV stores on plenty of workloads (Stonebraker & Pavlo, 2024).
• "Relational databases don't scale." Figma scaled Postgres ~100×; Notion runs 480 shards; Aurora processed 500 billion transactions in one shopping event. The honest version: scaling relational writes horizontally takes real engineering — that story is Scaling Writes & Partitioning.
• "The choice is SQL vs NoSQL." "NoSQL" lumps together five-plus families whose only shared trait is not being relational. A key-value store and a graph database have less in common with each other than either has with Postgres. Think in families, not in a binary.
• "Each family is a separate world." Nearly every major engine is multi-model now; Facebook's social graph runs on MySQL, Uber's documents run on MySQL, Postgres does vectors. Families are identities — what an engine is best at — not walls around what it can do.
• "New workload type → buy a new database." Watch the vector story: within a year, ANN search became an index inside existing engines. Before adding an engine, check whether your current one grew the feature — an index is cheaper than a runbook.

• A database family is a bet, frozen into the engine's storage layout, on which question you'll ask most — layouts make one access pattern nearly free and tax the rest.
• The eight bets: relational (correct records, any query) · key-value (this key, now) · document (whole aggregates) · wide-column (write-heavy, partition-wide) · graph (hop relationships) · time-series (append now, window later) · search (relevance to words) · vector (similarity to embeddings).
• Every family carries a production proof: 151M req/s (DynamoDB, Prime Day 2025), trillions of messages (Discord), 270B edges at 2M QPS (LinkedIn), 1.2B live series (Netflix) — specialization is real, not marketing.
• The 2026 twist: engines fractured, query models converged — everything speaks SQL-ish, everything is multi-model, so a family is an identity, not a wall. Ask "what was it built for?", not "what can it do?".
• One size fits none ≠ run eight databases: every added engine is a runbook, a sync pipeline, and the end of cross-store transactions. Default boring, stretch deliberately, specialize on measured evidence.
• Next: the family that earned the right to be the default — Relational Databases: The Default for a Reason.