How to Choose a Database
Every thread in this book braids into one working skill on this page: given a project, choose its database with reasons. Not with folklore, not with whatever the loudest blog recommends — with reasons you can state out loud and defend. The method is four questions and one prior. The questions: what shape is the data, what are the questions, what must never break, and how big and how fast. The prior: relational by default, something else only when a specific answer says so.
Lora made this choice in Chapter 1 without knowing she was making it. The Marquee's facts were tables-shaped, her questions cut across those tables in every direction, and a double-sold seat was unacceptable — three answers, all pointing the same way. You now get to make the same choice on purpose, for any project, because every question in the framework maps to a chapter you own.
The Four Questions, Armed
What shape is the data? You spent Chapter 2 learning the tables shape: declared columns, every row alike, relationships drawn with keys. And you spent Chapter 10 meeting its rival: nested, varying records where one film carries an awards list and another carries nothing. If the facts fall naturally into tables with shared structure, the shape question says relational. If every record is its own little world, it says document — and you know the price, because you watched the JOIN move into the application.
What are the questions? Chapter 4 taught you that real questions cross tables: who booked what, for which screening, of which film. Relational databases answer cross-cutting questions you haven't invented yet, which is their quiet superpower. But if the questions walk connections many hops deep — friends of friends of friends — you saw SQL groan at that in the graph topic. And if the only question is ever "the value under this key", you saw that a key-value store answers it faster than any query planner could.
What must never break? Chapter 7 gave you the transaction bracket and Chapter 6 gave you constraints, and together they are the honest test: does this project have a seat G7? Money, inventory, bookings, anything where two facts must change together or not at all — that demands the guarantees relational engines have spent fifty years hardening. A cache of tonight's screenings can be sixty seconds stale by agreement. A bank balance cannot.
How big, how fast? Chapter 10 named the pressures honestly: write floods that must spread across many machines, lookups by the million per minute. These pressures are real, and they are also rare at the size most projects ever reach. A single well-indexed relational database serves more traffic than most businesses will ever see — which is why this question comes last, and why answering it with a guess about future scale is the classic way to choose wrong.
The Default, Defended One Last Time
Why does every unsure branch lead to relational? Because it fits the widest range of shapes and questions, and because it keeps every door open. Constraints guard the data whether or not you remembered to. Transactions bracket the dangerous moments. And ad-hoc queries — the questions nobody thought of when the system was built — just work, because the schema was designed around nouns, not around one blessed query. Choosing relational is not a bet on any particular future; that is exactly what makes it a default.
A default is not a dogma. The framework can legitimately answer "not relational", and when it does, the deviation is visible: you can point at the question whose answer forced it. That visibility is the whole difference between engineering and fashion. Folklore says "MongoDB is faster"; the framework says "our records genuinely vary in shape, and we accept doing joins in the application". One of those survives being asked "why?" in a meeting.
Three Drills
A to-do app. Shape: users, lists, and tasks — tables, plainly. Questions: cross-cutting ("overdue tasks across all lists"), ordinary. Guarantees: nothing dramatic, but constraints cost nothing and catch bugs. Scale: modest by any honest forecast. Verdict: relational, boring, correct — and boring is a compliment; the interesting parts of a to-do app should be in the app, not in the data layer.
A chat product's message firehose. Shape: messages are simple and uniform, so tables fit. Questions: almost always "recent messages in this conversation" — key-shaped, narrow, known in advance. Guarantees: losing one message in a million hurts less than slowing every send. Scale: this is the real pressure — millions of writes a minute, spread across machines by design. Verdict: the message stream earns a wide-column store, chosen for a stated reason. Note what stays relational: accounts, contacts, billing — the core.
A personal blog. Shape: posts and comments, two small tables. Questions: a handful, all simple. Guarantees: a backup. Scale: none worth the name. Verdict: SQLite — the whole database in one file inside the app, zero servers to run — and go live. Reaching for a distributed anything here would be answering questions nobody asked.
Deviation Is Amendment, Not Exile
The family photo from the last chapter is what a mature answer looks like: the Marquee's bookings on a relational core, the homepage on a cache, film search on a search engine — each satellite chosen for a job, each one a rebuildable copy of truth that lives in the core. When a team says "we moved search to Elasticsearch", that is not the relational default failing. That is the framework working: a specific question got a specific answer, and the deviation is exactly as big as the job that earned it.
So hold the framework loosely enough to let it answer, and firmly enough that it must. Four questions, asked honestly, will carry you through every "Postgres or Mongo?" conversation of your career — including the ones where the right answer turns out to be "both, for different jobs", which is most of them.
- "Big companies use X, so we should." Their pressures are not yours yet — the write floods and machine-spreading from Chapter 10 arrive at sizes most projects never reach. And those companies run relational cores anyway; copying the satellites without the core copies the costume, not the engineering.
- "Choosing wrong is fatal." Migrations exist (Chapter 6), and satellites are rebuildable copies (Chapter 10's refrain), so most choices are revisable. The one mistake that truly resists revision is a rotten core schema — which is why Chapter 6 was the careful one.
- "The framework will always say relational, so it's just a slogan." It legitimately says otherwise — the chat drill shows it doing so, with the reason attached. The default is a prior, not a dogma; a framework that could only give one answer wouldn't be a framework.
- This page is the course's promise kept: you can now hold the "Postgres or Mongo?" conversation with reasons, which is what the introduction said you would leave able to do.
- The four questions turn every future database pitch — from a vendor, a blog, or an excited teammate — into a structured evaluation you can run in your head in under a minute.
Knowledge Check
A fitness app stores users, their workouts, and their subscription payments. The data is tables-shaped, questions cross tables freely, and payments must never be half-recorded. What does the framework say?
- Relational — every answer points at the default
- A document database, because workout data feels personal and varied
- A key-value store, because fitness apps need to feel fast
- A wide-column store, in case the app becomes huge later
Which answer to the four questions genuinely justifies leaving the relational default?
- "The database we'd deviate to is very popular right now"
- "We might get big someday, so we should prepare now"
- "The only query is key-shaped, at millions of writes a minute, spread across machines"
- "Our questions cross the data in complicated ways that we haven't fully planned out yet"
Why are most database choices revisable — and which one isn't?
- All engines are slowly becoming exactly the same product over time, so the choices stop mattering
- Migrations reshape schemas and satellites are rebuildable, but a bad core schema resists it all
- Vendors offer refunds and migration services, except for the oldest engines
- Backups make everything reversible, except choosing the wrong cache
A team says: "We moved our product search to Elasticsearch." According to this page, what happened?
- The relational default completely failed, so now the whole team is migrating away from it entirely
- A job earned a specialist satellite while the relational core stayed — the framework working
- The team followed fashion, since search worked fine in SQL
- The team now has two sources of truth that will drift apart
You got correct