Choosing Your Database
In one line: this decision gets made in interviews in about ten seconds, usually badly. Doing it from the access pattern rather than from reputation is one of the clearest senior signals available.
The baseline criteria
| Choose a relational database if... | Choose a non-relational database if... |
|---|---|
| The data to be stored is structured | The data to be stored is unstructured |
| ACID properties are required | There's a need to serialize and deserialize data |
| The data is relatively small and fits on a node | The size of the data to be stored is large |
Three criteria: structure, guarantees, scale. Most decisions are settled by one of them.
A decision flow
The branch that matters most is the second one. Do you need transactions across multiple records? If yes, relational is the path of least resistance and staying there is usually right. If no, the access pattern picks the family for you.
Matching workload to family
| Workload | Choice | Why |
|---|---|---|
| Payments, orders, inventory | Relational | Multi-row atomicity and constraints are the entire requirement |
| User sessions, shopping carts | Key-value | Lookup by a single identifier, extremely high rate, no relationships |
| Product catalog with varying attributes | Document | Each record is self-contained and differently shaped |
| Social graph, recommendations, fraud rings | Graph | The relationships are the query |
| Analytics over billions of rows | Columnar | Scans few columns across many rows |
| Time-series metrics, event logs | Wide-column | High write throughput, semi-structured, append-heavy |
Polyglot persistence is the realistic answer
Real systems rarely pick one. An e-commerce platform reasonably runs relational for orders and payments, a key-value store for sessions and carts, a document store for the catalog, and a columnar warehouse for analytics — because those four workloads have genuinely different shapes.
Saying "different data, different store, here's the boundary between them" is a much stronger answer than forcing one database to serve every access pattern. The cost you take on is operating several systems and keeping them in sync, so name that too.
The most common mistake in this decision
Choosing NoSQL for scale you do not have, and paying for it in correctness you do need.
A single well-provisioned relational node handles far more than most people assume — comfortably into billions of rows and tens of thousands of transactions per second. Reaching for eventual consistency and hand-rolled referential integrity before you have measured a real limit means taking on the costs of distribution with none of its benefits.
The scaling ladder from the Foundations module applies here exactly: scale up while it's cheap, and design so you can scale out when you must.
The gap is narrowing
The clean SQL-versus-NoSQL split this lesson describes is becoming less sharp. Modern NewSQL databases such as Google Cloud Spanner combine the horizontal scalability of NoSQL with the ACID guarantees and SQL interface of relational systems.
That matters for the "does it fit on one node?" branch above. Historically, outgrowing a single node forced you to abandon transactions. NewSQL removes that forced choice — at the cost of the coordination latency the Foundations module priced out, since strict serializability across regions still requires consensus on the write path.
| Era | Scale | Transactions | The forced trade |
|---|---|---|---|
| Classic relational | One node | Full ACID | Hit a ceiling and stop |
| NoSQL | Horizontal | Weak or single-record | Give up transactions to scale |
| NewSQL | Horizontal | Full ACID | Pay coordination latency on writes |
Key takeaway
Decide from the access pattern and the guarantees you need, not from which system is fashionable. And check whether the scale that supposedly forces your hand is real, measured, and imminent — it often isn't.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | "NoSQL, because we need to scale." |
| L5 | Splits by workload: "relational for orders since we need transactions, and a key-value store for sessions since it's pure lookup by ID." |
| Staff+ | Questions the premise and prices it: "before going distributed I'd check whether one node actually can't hold this — it usually can. If it genuinely can't and I still need transactions, that's NewSQL and I'm paying consensus latency per write. Otherwise polyglot: relational for money, document for catalog, and I'll own the sync between them." |
Next: keeping more than one copy of the data.