SQL vs. NoSQL: Choosing a Database — System Design Fundamentals

The SQL vs. NoSQL question is really several smaller questions bundled together, and "NoSQL is more scalable" is not, on its own, a real answer — plenty of relational databases run at enormous scale.

What actually differs

	Relational (SQL)	Non-relational (NoSQL)
Schema	Fixed, enforced at write time	Flexible / schema-less
Relationships	First-class (joins, foreign keys)	Usually denormalized instead
Consistency	Strong by default (ACID transactions)	Often eventual, tunable
Scaling model	Vertical first, horizontal is harder	Built for horizontal from the start
Query flexibility	Arbitrary queries via SQL	Often optimized for specific access patterns

The question that actually decides it

Not "which is faster" — "do I know my access patterns in advance, and do they need multi-record transactions?"

If your data has real relationships you need to query flexibly (a JOINs-heavy admin dashboard, financial records, anything needing multi-row transactions) — relational is usually right, even at scale.
If you have one or two dominant, known access patterns ("get a user's timeline by user ID," "get a product by SKU") and need to scale horizontally without operational pain — a NoSQL store built around that access pattern (DynamoDB, Cassandra, MongoDB) often fits better, because you can denormalize around the query instead of normalizing around the data.

A concrete rule of thumb

Need ACID transactions across multiple records?        → SQL
Schema will change frequently and unpredictably?        → NoSQL
Access pattern is a single, known lookup (by key)?       → NoSQL
Need arbitrary, ad-hoc queries across relationships?     → SQL

Most real systems end up using both — a relational database for the core transactional data (orders, accounts, payments) and a NoSQL store for a specific high-volume, simple-access-pattern workload (session data, activity feeds, caching layers). "Pick one database for the whole system" is itself often the wrong framing.