Reqflow
← All concepts
Data·3 min read

SQL vs NoSQL

Pick relational when you need joins + transactions; pick a NoSQL store when you need a specific scaling property they're built for.

Try it

Pick a scenario below and see which option fits, and why.

SQL
relational, strong consistency, joins
NoSQL
flexible schema, scales horizontally
Scenarios

There is no universal winner here, only the right fit for a given situation. Each scenario above pushes the decision a different way, which is exactly how this tradeoff shows up in real design questions.

First time reading this? Start here

Plain English: SQL is great when your data is tables that connect to each other (users + orders + products) and you need correctness. NoSQL trades some of that flexibility for one specific strength, usually huge write volume or an unusual shape of data.

Used in:URL ShortenerWhatsAppTikTokYelp

What it is

SQL (relational) databases enforce schemas, support transactions, and are optimized for normalized data with relationships. NoSQL is a broad category covering key-value (Redis), document (MongoDB), wide-column (Cassandra), and graph (Neo4j) stores, each optimized for a specific access pattern that traditional SQL handles poorly.

The problem it solves

Not every workload fits a relational model. High-volume time-series writes, schemaless documents, huge horizontal scale, sub-millisecond key lookups: these have stores purpose-built for them. SQL is the right default; NoSQL is the right answer when you have a specific reason.

How it works

SQL: structured tables, joins, ACID transactions, strong consistency, vertical scaling (mostly). NoSQL families: key-value (O(1) lookup, no joins), document (flexible schema per row), wide-column (write-heavy time-series, sharded by partition key), graph (relationship-heavy queries).

Why use it

  • SQL: rock-solid transactional guarantees, joins, mature tooling, well-understood
  • NoSQL: each family scales horizontally in ways SQL struggles with
  • Schema-less NoSQL is forgiving during rapid iteration

What it costs you

  • SQL hits vertical limits, and sharding it is painful (see Vitess, Citus)
  • NoSQL gives up properties (consistency, joins, transactions) for that scale, so make sure you can live without them
  • 'NoSQL' isn't one thing, and picking the wrong family is worse than picking SQL

Where it shows up in our architectures

  • URL Shortener →

    Postgres: relational fits, scale is modest

  • WhatsApp →

    Cassandra: write-heavy time-series log, sharded by conversation

  • TikTok →

    Cassandra for activity events; Postgres would melt at the write volume

  • Yelp →

    Postgres for business records; Cassandra for reviews, since they have different access patterns and need different stores

Gotchas

  • Default to SQL. The number of teams that needed Cassandra is much smaller than the number that adopted it.
  • Cassandra/DynamoDB excel at write-heavy time-series. They are terrible for ad-hoc queries.
  • MongoDB's appeal (schemaless) is also its risk; schema enforcement at the DB level prevents whole categories of bugs.
  • You can run multiple stores: Yelp uses Postgres AND Cassandra. Match the store to the workload.
Interview angle

SQL vs NoSQL questions test whether you default to the right tool or just chase hype. The signal interviewers want is that you start with SQL and only move to NoSQL when you can name a specific property you need (write throughput at Cassandra scale, sub-millisecond key lookup, flexible schema for rapidly evolving documents). Candidates lose points by reaching for MongoDB or DynamoDB reflexively without articulating what SQL couldn't handle.

Your notes

Private to you