Stop 06 · Database ServicesTopics · 9/10

Choosing the Right Database

In short

'Which database should we use?' comes up in every system design interview and every new project. The honest answer starts with questions about your data, not with the trendiest product name.

Matching database type to workload — relational for structured data with complex relationships, NoSQL for massive scale and flexible schemas, caching for speed, warehousing for analytics — a recurring architecture decision.

The blob character looks at a pressure cooker, a kadhai and a tawa on a counter.

Think of it like this

Cooker, kadhai or tawa

Dal goes in the pressure cooker, sabzi in the kadhai, rotis on the tawa. You could force a roti into a cooker, but why? Each database type is a utensil built for one kind of cooking, and good kitchens use several.

Watch it happen

Start from the question you ask most

Main need?

Joins + txns

Relational (RDS)

Huge key lookups

NoSQL (DynamoDB)

Same reads, fast

Cache (Redis)

Big reports

Warehouse

1/5Ask how the app reads and writes data, how big it gets and how consistent it must be.

The big ideas

What you need to know

Relational by default

If you're unsure, PostgreSQL or MySQL on a managed service handles most apps well for a long time.

NoSQL for known patterns

Choose it when access patterns are clear and scale is huge. Changing patterns later is painful.

Use more than one

Many systems combine a relational core, a cache, a search engine and a warehouse. Each does its own job.

Team skills count

A database your team understands well usually beats a 'better' one nobody knows how to run or tune.

Save yourself the pain

Common mistakes

Oops

Picking NoSQL because it 'scales better' for a college project with 100 users.

Do this instead

At small scale a relational database is simpler and more flexible. Pick NoSQL when you have a real reason.

Oops

Forcing one database to do everything.

Do this instead

Running analytics on the app database or full-text search with LIKE '%x%' hurts. Add the right tool for that job.

Your mission

Design the data layer for a food app

~25 min

Quick check

A banking app needs transfers where money leaves one account and enters another, all or nothing. Best fit?

Go deeper

1Match 3 hypothetical workloads to the most appropriate database type from this phase.
2Learn to ask about access patterns and consistency requirements before choosing a database.
3Practice justifying a database choice with specific reasoning, not just familiarity.