NoSQL · Data models beyond tables
How do you choose a database for a new system?
Short answer
Start from access patterns, consistency, scale, operational maturity and team skills, then benchmark the shortlist with realistic data. Avoid choosing by trend or by a single benchmark number.
A database choice is an architectural commitment. The right question is not which database is best, but which one satisfies the workload with acceptable complexity and risk. That includes how the team will operate it at 3 a.m.
A decision framework
- Access patterns: key lookups, ranges, joins, aggregations, full-text or graph traversal
- Consistency: what stale data costs, and whether transactions are required
- Scale: current and projected volume, write rate and latency target
- Operations: managed service availability, backup, failover, upgrades and observability
- Team: existing expertise and on-call capacity
- Ecosystem: drivers, migrations, local development and vendor lock-in
Benchmark the shortlist with a realistic schema, data volume and query mix. A vendor benchmark with uniform keys and no contention can hide the failures you will actually hit, such as hot partitions, replication lag or compaction pauses.
Consider a polyglot design only when the benefit is concrete. Each additional store adds a consistency boundary, a backup process, a failure mode and a skill to maintain. A single well-understood database is often the cheaper long-term choice.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1What would make you choose a relational database over a NoSQL one?
- 2How do you evaluate operational maturity, not just features?
- 3When is a polyglot persistence architecture justified?
- 4What would you test in a proof of concept?
Say it in the interview
I start from the workload: access patterns, consistency requirements, scale and latency targets. Then I weigh operational maturity and the team's ability to run the system, because a database that is hard to operate is a long-term cost. I benchmark a shortlist with realistic data and contention rather than trusting a vendor number. I only add a second database when the benefit is concrete, since every extra store adds consistency, backup and failure-mode complexity.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.