The Three Shapes of Data Storage
Most databases fall into three families. You don't need to memorize products — you need to recognize which shape fits your problem.
| Type | Examples | Best for | Trade-offs |
|---|---|---|---|
| Relational () | PostgreSQL, MySQL, SQLite | Structured data with relationships; anything money- or accuracy-critical | You must design a schema up front; scaling writes very large is harder |
| Document / | MongoDB, Firestore, DynamoDB | Flexible or nested data, fast iteration, varied record shapes | Easy to create inconsistent data; relationships and reporting get awkward |
| Key-Value | Redis, Memcached, Cloudflare KV | Caching, sessions, counters, fast lookups by a known key | No querying by content; usually not your source of truth |
The three shapes store data in genuinely different ways. Picture them side by side:
RELATIONAL (SQL) DOCUMENT (NoSQL) KEY-VALUE
rows + columns self-contained blobs one key → one value
┌────┬───────┬──────┐ ┌──────────────────┐ ┌─────────┬─────────┐
│ id │ email │ name │ │ { │ │ key │ value │
├────┼───────┼──────┤ │ id, email, │ ├─────────┼─────────┤
│ 1 │ a@... │ Ana │ │ name, │ │ session │ "x9f2" │
│ 2 │ b@... │ Bob │ │ posts: [ ... ] │ │ count │ "42" │
└────┴───────┴──────┘ │ } │ └─────────┴─────────┘
tables reference └──────────────────┘ no querying inside —
each other everything nested look up by key only
Think of a relational as a set of spreadsheets that know how to reference each other. The language you use to talk to one is SQL (Structured Query Language). A good default for 90% of projects: start with a relational database (Postgres). It is mature, predictable, enforces structure, and handles the relationships real apps inevitably grow. Reach for document stores when your data is genuinely shapeless, and key-value stores as a supporting layer (caching), not your primary store.
The trap to avoid is choosing by vibe. "NoSQL (databases that don't use SQL tables — they store flexible, free-form records) scales better" is true only for a narrow set of problems most apps never hit, and even then the price is giving up the consistency guarantees that make data trustworthy. Pick the shape that matches your data, not the one that sounds most impressive in a system-design video. When you're unsure, relational is the safe bet — you can always add a or a document store later, but unwinding a tangled NoSQL data model is painful.