How do you choose between relational and NoSQL databases?

WHAT THIS TESTS This checks whether you can drive a database choice from requirements and access patterns rather than from hype. It also surfaces whether you understand that modern databases blur lines, since PostgreSQL has JSONB and MongoDB has multi-document transactions.

A GOOD ANSWER COVERS Start with the data shape and relationships. Relational databases enforce a schema, support normalization, and excel at ad hoc queries with joins across many entities, plus strong ACID guarantees that simplify correctness for money and inventory. Document databases let each record carry a flexible structure, which suits rapidly evolving fields or naturally hierarchical data, and they were built to scale horizontally by sharding. Next discuss consistency needs, transaction scope, read versus write ratios, and reporting requirements. Mention operational maturity, tooling, and team familiarity as real factors.

COMMON WRONG ANSWERS Saying NoSQL is inherently faster or more scalable than SQL; both can scale, and a well-indexed relational query often beats a poorly modeled document scan. Another mistake is equating schemaless with no design needed, when document modeling still demands careful thought about access patterns. Ignoring that PostgreSQL supports JSON and that MongoDB supports transactions shows a dated mental model.

LIKELY FOLLOW-UPS How would you model a many-to-many relationship in MongoDB? When does PostgreSQL stop scaling vertically? How do you handle schema migrations in each? What does a polyglot persistence approach look like?

ONE CONCRETE EXAMPLE A fintech ledger with complex joins, reporting, and strict transactional integrity points clearly to PostgreSQL. A product catalog where each item type has wildly different attributes, with mostly key-based reads and high write volume, fits a document model well, since each product fetches as a single self-contained document without joins.