Choosing Your Database
Why this matters: 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.
Key takeaway
The choice between relational and non-relational depends on your specific requirements — the shape of the data, whether you need ACID, and the size relative to a single node.
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 |
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.