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.

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 Shortener WhatsApp TikTok Yelp

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.

Your notes

Private to you