The database is usually the hardest part of a system to change later and the first thing that falls over under load, so picking the right one is one of the highest-leverage decisions you make in an interview. The goal of this lesson is to give you a decision framework, not a list of product names to memorize.
Weak candidates open with "I'll use SQL" or "I'll use NoSQL" as a reflex. Strong candidates first answer three questions: What does the data look like (how is it related)? How will it be read (by key, by range, by ad hoc filters, by joins)? What is the read/write volume and how must it grow? The right database falls out of those answers. Say this out loud in the interview, then choose.
Data lives in tables of rows and columns with a fixed schema. You get SQL for flexible querying, joins across tables, secondary indexes, and ACID transactions (Atomicity, Consistency, Isolation, Durability) so multi-step operations are all-or-nothing. Examples: PostgreSQL, MySQL, and cloud engines like Aurora, Spanner, and CockroachDB.
Reach for relational when you have structured, related data, need multi-row transactions (money, inventory, bookings), or when the queries are not fully known up front and you want the freedom to ask new questions. A single well-tuned Postgres node handles tens of thousands of writes per second and terabytes of data before you must shard, so it is a strong default for most systems.
NoSQL is not one thing. It is a family of stores that each drop some relational features to buy horizontal scale, flexible schema, or a specialized access pattern.
SQL gives you flexible queries, joins, and strong transactional guarantees on a single node, at the cost of more effort to scale writes horizontally. NoSQL gives you easy horizontal scale and schema flexibility, but only if you design around a small set of known access patterns, and it often relaxes consistency or drops joins. In one sentence: SQL optimizes for flexibility of querying, NoSQL optimizes for scale of a known query.
Note that the old "SQL cannot scale" claim is outdated. Read replicas, partitioning, and distributed SQL engines like Spanner and CockroachDB scale relational workloads very far. Do not use scale alone as your reason to abandon SQL.
Real systems rarely use one database. A single product might use Postgres for orders and payments, Redis for sessions and rate limits, Cassandra for the activity feed, and Elasticsearch for search. Picking the right store per workload, rather than forcing everything into one, signals senior thinking.
"Let me start from the access patterns and consistency needs. This data is relational and needs transactions at moderate scale, so I will use a relational database like Postgres, add read replicas for read-heavy traffic, and shard later only if writes outgrow a single primary. For the session and rate-limit data I will use a separate key-value store."