"SQL or NoSQL?" is one of the most common forks in a system design interview, and one of the most botched. People treat it like a trivia question with a right answer. It isn't. The interviewer wants to hear you reason about your data and the access patterns, then justify a choice. Pick either one and defend it well, and you pass that part of the round. Pick the right one and fumble the why, and you don't.
Here's how I think about it under pressure.
Start with the data, not the database
Before you say a single product name, describe your data. Two questions get you most of the way:
- What are the entities, and how do they relate?
- How will you read and write them at scale?
If your data is highly relational and you'll query it in ways you can't fully predict yet (joins across users, orders, payments, reviews), relational databases earn their keep. If your access pattern is narrow and known up front (give me everything for this one key, fast, at huge volume), a NoSQL store fits the shape better.
The mistake is leading with "I'll use Postgres" or "I'll use DynamoDB" before you've said what you're storing. Name the data first. The database falls out of it.
What SQL actually buys you
Relational databases give you a few real things, and you should say them by name:
- Joins and flexible queries. You don't have to know every query in advance.
- ACID transactions. Money movement, inventory, anything where a half-finished write is a bug, not an inconvenience.
- Strong consistency by default.
- A schema that enforces shape, which catches whole classes of bad data.
The classic pushback is "SQL doesn't scale." That's mostly outdated. A single Postgres or MySQL box handles a lot, and you scale reads with replicas. The real ceiling is write throughput on a single primary, which is where sharding comes in, and sharding is genuinely harder in a relational world because cross-shard joins and transactions get ugly.
So the honest framing is: SQL scales fine until you need to shard writes across many machines, and that's the point where it gets painful.
What NoSQL actually buys you
NoSQL is a category, not one thing. Be specific about which kind:
- Key-value (DynamoDB, Redis): fast lookups by key, easy horizontal scaling.
- Document (MongoDB): flexible nested records, good when shape varies.
- Wide-column (Cassandra): heavy write volume, tunable consistency.
- Graph (Neo4j): relationship-heavy traversal like social graphs.
The shared win is horizontal scale and predictable performance for known access patterns. The cost is that you usually design the schema around your queries, not the other way around. Change your access pattern later and you may be reshaping data or adding secondary indexes.
The other cost people forget to mention: many NoSQL systems are eventually consistent by default. That can be totally fine for a feed or a view counter and a real problem for a bank balance. Say which one you're dealing with.
The decision in one breath
When the interviewer asks, you want an answer that sounds like this:
"The core data here is relational and I need transactional guarantees on payments, so I'll start with Postgres. If the product-catalog reads become the bottleneck, I'll put them behind a cache or move that piece to a key-value store. I don't want to give up transactions on the part that handles money."
That answer does three things. It picks something. It names the tradeoff. And it leaves a door open for evolving the design. That's the level you're aiming for.
It's usually both
Real systems rarely pick one. A common shape is Postgres for the source of truth, Redis for caching hot reads, and something like Elasticsearch for search. If your design uses two stores, say why each one is there and how you keep them in sync. "Postgres is the system of record, Redis is a read-through cache, and search runs off a separate index we update asynchronously" is a strong sentence to be able to say.
Mistakes that cost points
- Naming a database before describing the data.
- Saying "NoSQL scales better" with no detail. Scales how, for which access pattern?
- Claiming a NoSQL store gives you joins for free.
- Ignoring consistency. If money or inventory is involved and you don't mention transactions, that's a flag.
- Refusing to commit. "It depends" is not an answer unless you then make a call.
How to get good at this
The fork itself is fast once you've said it out loud a dozen times. The way I'd practice is to take five common prompts (URL shortener, news feed, ride matching, chat, e-commerce checkout) and for each one say which store you'd use and the one tradeoff that drives it. Do it as a mock interview if you can, because saying it under mild pressure is different from knowing it on paper.
The goal isn't to memorize a lookup table of "this app uses this database." It's to reason from the data to a defensible choice, out loud, in about thirty seconds.