AlgoInsight

System Design

How to Choose a Database in a System Design Interview

Pick the wrong database in an interview and everything downstream wobbles. After years of choosing databases for systems that ingest billions of events a day, here's the framework I actually use - and how to apply it under interview pressure.

By Admin2026-06-1815 min readdatabasesystem-designsqlnosqlinterviewdata-modeling

In a system design interview, the database choice is one of the most consequential decisions you'll make - and one of the most revealing. Choose well and the rest of your design has solid ground to stand on. Choose poorly, or worse, choose without being able to say why, and a sharp interviewer will pull on that thread until the whole design unravels. I've chosen databases for systems handling billions of events a day, and I've also sat across the table watching candidates freeze on "so, what database would you use here?"

The good news: there's a framework, and it's not complicated. It's a small set of questions you ask about the data and the workload, and the answers point you to the right kind of database. Here's the framework I actually use, adapted for the pressure of a 45-minute interview.

The mistake to avoid first

Before the framework, the trap. The weakest answer to "what database would you use" is naming a specific product immediately - "I'd use Postgres" or "I'd use MongoDB" - with no reasoning behind it. It signals you're pattern-matching to something familiar rather than reasoning about the problem in front of you. The second-weakest answer is "it depends," and then stopping. Of course it depends - the interviewer wants to know on what, and to watch you reason through it.

The strong answer reasons from the requirements to a category of database first, then optionally names an example. So the framework isn't about memorizing which database to use for which app - it's about asking the right questions about your data and letting the answers guide you.

The questions that actually decide it

Here are the questions I ask, roughly in order of how much they tend to matter.

1. What's the access pattern?

This is the most important question, and the one candidates most often skip. How will the data be read and written? Specifically:

The access pattern is the foundation. A database that's perfect for one access pattern can be terrible for another, so understanding how the data will actually be used comes before everything else - before structure, before consistency, before scale. Get the access pattern wrong and every later decision is built on sand.

2. What's the data's structure?

How structured and related is the data?

3. What are the consistency requirements?

How critical is it that every read sees the latest write, immediately?

This is where the CAP theorem lurks: at scale, strong consistency trades against availability and partition tolerance, so naming your consistency requirement is naming a fundamental trade-off. (See the dedicated guide on consistency models.)

4. What's the scale, now and later?

How much data, and how fast is it growing?

graph TD
    A[What database?] --> B{Complex queries,<br/>joins, relationships?}
    B -->|Yes| C{Strong consistency<br/>critical?}
    B -->|No, simple lookups| D{Massive scale,<br/>flexible data?}
    C -->|Yes| E[Relational / SQL]
    C -->|Eventual OK| E
    D -->|Yes| F[NoSQL<br/>key-value / document / wide-column]
    D -->|Moderate| E

This decision tree shows how to narrow the database choice. Start by asking whether you need complex queries, joins, and relationships. If yes, a relational SQL database is usually right, especially if strong consistency matters. If you only need simple lookups, ask whether you have massive scale and flexible data - if so, a NoSQL database such as key-value, document, or wide-column fits; if the scale is moderate, a relational database still works well.

Mapping answers to database types

Once you've answered those questions, the category usually becomes clear. The main types, and when each fits:

Tip: Here's something experience taught me that interviews rarely acknowledge: a well-run relational database handles far more than people expect. I've seen candidates jump to exotic NoSQL systems for scale they'll never reach, when a relational database with proper indexing, caching, and read replicas would serve them beautifully and keep the powerful querying they'll miss once it's gone. "Use a relational database, and scale it with caching and replicas" is a strong, defensible answer for a huge range of systems. Reach for NoSQL when you have a specific reason the relational model doesn't fit - massive write scale, genuinely flexible data, or an access pattern relational databases handle poorly - not because NoSQL sounds more impressive.

A worked example: applying the framework

Let me run the framework on a concrete prompt. Suppose the interviewer says "design the backend for an e-commerce store." When the database question comes, I don't name a product - I reason through the questions.

Access pattern: read-heavy (people browse far more than they buy), with a mix of simple lookups (show this product) and complex queries (orders for a customer, products in a category, sales reports). Structure: highly relational - customers, orders, order items, products, all with clear relationships I'll query across. Consistency: the order and payment data needs strong consistency (you can't have an order half-placed or wrong inventory), while the product catalog tolerates slight staleness. Scale: substantial but not extreme - well within what a relational database plus caching and replicas handles.

So I commit: "A relational database for the core data - customers, orders, products - because the data is highly relational, I need joins and complex queries, and the order/payment path needs strong consistency. Since it's read-heavy, I'll add a cache for hot reads like the product catalog and read replicas to spread query load. If product search becomes important, I'd add a dedicated search index for that specifically."

Notice the shape: reason through access pattern, structure, consistency, and scale; commit to a category with justification; add supporting stores (cache, search) for specific needs. That's a complete, defensible decision - and I never named a specific product.

Common systems and their typical database fit

To build intuition, here's how the framework tends to resolve for common system types:

These aren't rules to memorize - they're what the framework produces when applied to each pattern. Internalize the reasoning, and you can derive these (and handle the systems not on this list) yourself.

The follow-ups interviewers will ask

Once you've chosen, a good interviewer probes - and being ready is part of answering well:

Handling these follow-ups confidently turns a database choice from a single answer into a demonstration of understanding. The choice itself matters less than your ability to defend it.

A word on not over-engineering

One final piece of judgment experience teaches: there's a temptation to reach for complex, exotic database setups to look sophisticated - polyglot architectures with five data stores for a system with modest needs. Resist it. The strongest engineers match the solution's complexity to the actual requirements. If a single relational database with a cache serves the system well, that is the sophisticated answer, because it's simplest to build, operate, and reason about. Adding a wide-column store and a graph database and three caches to a system that doesn't need them isn't impressive - it's over-engineering, and a good interviewer sees through it. Choose the simplest set of databases that genuinely meets the requirements, and add complexity only where a specific need demands it.

How to deliver it in the interview

Knowing the framework is half the battle; using it well under pressure is the other half. The move that scores: think out loud through the questions, then commit. Something like: "This is read-heavy with complex queries across related data, and we need strong consistency for the financial parts, so I'll use a relational database - and since it's read-heavy, I'll scale reads with caching and replicas."

Notice what that does. It states the access pattern, the structure, and the consistency need; it reasons to a category; and it commits to a choice with justification. That's exactly what the interviewer wants to see - not the "right" database (there's rarely one right answer), but the reasoning connecting requirements to choice.

And don't be afraid to use different databases for different parts of the system. A real system often uses a relational database for its core transactional data, a cache for hot reads, a search index for search, and object storage for files. Recognizing that you can pick the right tool for each part - rather than forcing everything into one database - is a senior-level signal.

Interview: When I evaluate a database choice, I'm barely listening for which database. I'm listening for whether you reasoned from the access pattern, the data structure, the consistency needs, and the scale - and committed to a choice you can defend. A candidate who says "I'll use Postgres" and can't say why is weaker than one who says "I'll use a relational database because the data is relational, we need joins, and consistency matters here, and I'll scale reads with caching." Reason to the category, justify it, and you've answered the question well - even if I'd have chosen differently. The choice is rarely unique; the reasoning is what's being assessed.

The bottom line

Choosing a database in an interview isn't about memorizing which product fits which app - it's about asking the right questions and reasoning to a category. The questions that decide it: what's the access pattern (read/write balance, simple lookups versus complex queries), how structured and related is the data, how strong must consistency be, and what's the scale now and later. Those answers point you to relational, key-value, document, wide-column, or a specialized store. And a quiet truth from running real systems: a well-run relational database with caching and replicas serves a far wider range of problems than people assume - reach for NoSQL when you have a specific reason, not for impressiveness.

Reason out loud from requirements to choice, commit with justification, and use different tools for different parts where it helps. Do that, and the database question becomes one of the strongest parts of your design. We work through database selection and data modeling across System Design Fundamentals.

Go deeper

More articles