Share this letter & I’ll send you some rewards for the referrals.
Some of these are everyday databases, and some are quite specialized. ALL of them are super useful to software engineers building production systems.
Curious to know how many were new to you:
Relational,
Document,
Key value,
Wide column,
Graph,
Time-series,
Geospatial,
Vector,
Search engine,
In-memory,
Distributed SQL,
Embedded,
Columnar,
Data lakehouse,
Object storage,
Ledger.
For each, I’ll share:
What it is & how it works (in simple words),
A real-world analogy,
Tradeoffs,
Why it matters.
Let’s go!
§
Autonomous Software Development for the Enterprise (Partner)
Blitzy is built for large, complex software projects that other coding agents cannot handle: new feature development, large-scale refactors, scaled vulnerability remediation, and undocumented legacy systems.
Blitzy’s Sandbox lets engineers evaluate Blitzy on their own software estate, at their own pace. Eligible organizations can connect real applications, reverse-engineer up to 1 million lines of code, generate up to 25,000 lines of E2E tested code, and surface prioritized security vulnerabilities across their software estate.
(Thanks to Blitzy for partnering on this newsletter.)
§
1. Relational
A relational database stores data in tables of rows and columns, and links those tables through shared keys. Every row follows the same shape, and keys tie the tables together.
You declare the shape upfront in Structured Query Language (SQL).
So a customer row carries an identifier, a name, and an email. Orders live in their own table and carry the customer identifier, and the database matches the two on that column in an operation called a join.
Transactions group several changes into one unit, so money moves between two accounts completely/both rows stay as they were. This guarantee is atomicity, consistency, isolation, and durability (ACID), and it is why banks and shops still run on these engines fifty years on. PostgreSQL also reaches beyond the model through extensions, adding geography and vector search to the same database.
One schema, one set of rules, and every application connecting to it gets the same answer.
Analogy
A warehouse with a strict intake form.
Every pallet carries the same label fields, so any driver finds any pallet by reading a code. Redesign the form, and you relabel the whole warehouse.
Tradeoff
Relational databases hand you correctness for free, with joins, constraints, and transactions built in.
But the fixed schema resists change, and adding a column to a large table can lock it while the change runs. Plus, write throughput hits a ceiling on one machine; lifting that ceiling means sharding by hand1.
Why it matters
Orders, payments, inventory, users, and any data with real relationships.
PostgreSQL & MySQL cover most of this ground. Pair it with in-memory caching and distributed SQL, which take over once reads and writes outgrow a single box.
2. Document
A document database stores each record as one self-contained document, typically in JavaScript Object Notation (JSON).
Two documents in the same collection2 can “differ”.
One product carries a shoe size, and the next carries a screen resolution & a warranty period. The database keeps each one whole,,, so a single read returns the entire product with every nested field attached and no join runs.
Indexes still apply to any field/path you name, including nested fields and array elements, so queries stay fast as collections grow. MongoDB & Couchbase lead here, and support transactions across several documents.
The freedom lives in the “schema”, and speed still comes from disciplined indexing.
Change the fields on one product and the rest of the collection carries on unchanged.
Analogy
A filing cabinet of case folders.
Each folder holds every page for one case, so you answer any question about it by pulling one folder. Nobody checks whether two folders hold the same kind of pages.
Tradeoff
Document stores let each record carry its own shape… This suits data nobody can pin down in advance.
But copies of the same fact spread across documents and drift apart, and relationships between documents fall to your application code. With the schema left open, malformed records reach production quietly & surface months later.
So validate the shape in the database, since the flexibility you want in year one becomes the mess you inherit in year three.
Why it matters
Catalogs, user profiles, content, and event payloads, where records vary, and you read them whole.
MongoDB and Couchbase are popular picks. Pair it with a search engine for text queries, or move to a key-value store when every read is by identifier anyway.
3. Key-value
A key-value store saves a value under a unique key & returns it in a single lookup.
The “key” is the only way in3.
Ask for one key and the store answers in one hop, with no scan & no query planner in the way. The store hashes4 each key onto one node, so adding nodes splits the keyspace and lifts capacity in a straight line. Plus, many KV stores attach a time-to-live so cached entries expire on their own.
Redis & DynamoDB dominate this space.
Analogy
A coat check.
You hand over a coat and get a numbered ticket… the ticket brings the coat back in seconds. The attendant has no other way to find every brown coat in the room.
Tradeoff
Key-value stores give you the fastest read path & scale by adding nodes.
But every lookup by something other than the key means a full pass over the data, and secondary indexes stay limited/absent. Also one “popular” key sends all its traffic to a single node, so a HOT key overloads one machine while the rest idle.
So design the key naming scheme5 before you write a line of code, because reworking it later means rewriting each caller.
Why it matters
Sessions, shopping carts, feature flags, and rate limit counters, where you know the identifier at read time…
Redis & DynamoDB are the standards. Pair it with a relational database, which holds the truth, while the key-value6 store holds the fast copy.
§
§
4. Wide-column
A wide-column store spreads rows across many nodes & each row holds only the columns it uses.
The primary key does double duty7:
Its first part (partition key) decides which node stores the row.
Its second part (clustering key) decides the order of rows inside the partition.
Pick both well & a query reads one partition on one node… this is how wide column stores answer in milliseconds while holding petabytes.
Writes take a fast path too: they append to a commit log & an in-memory table8 before flushing to sorted files on disk. So nothing seeks across the disk to update a row in place.
Get the key right & a read touches only one node… Get it wrong & it touches all of them…
Analogy
A stadium with numbered gates…
Your ticket names the gate, so you walk straight in while sixty thousand people move at once. Arrive without a gate number, and you circle the building.
Tradeoff
Wide-column stores take write volumes9 no single machine survives, and they stay available while nodes fail.
But you model queries before you model data, so a question nobody anticipated needs a second table and a second copy10. Plus, deletes leave markers11 behind until compaction clears them, and repair, compaction, & node replacement are real operational work.
So write down every query you need before you design the key, since the model resists new questions later.
Why it matters
Message history, activity feeds, and device telemetry at write volumes one machine will never take…
Cassandra & HBase lead here. Pair it with a time-series database,,, which gives you the same scale with far less modeling when the data is stamped with a time.
5. Graph
A graph database stores data as nodes & edges between them, then answers questions by walking those edges.
The relationship gets stored12, so following it costs almost nothing.
In a relational database, finding friends of your friends means joining a table to itself once per hop, and each hop multiplies the work. A graph database keeps a direct pointer from every node to its neighbors, so a hop is a pointer follow & depth stops mattering13.
Query languages like Cypher & Gremlin let you describe the shape you want and the engine traces it.
Analogy
An underground map…
You trace the route with your finger without reading a single timetable.
Tradeoff
Graph databases answer questions about connections, and the queries read like the question you asked.
But spreading a graph across machines is HARD, since edges cross partitions & traversal then crosses the network14. Also you need to learn a new query language, plus bulk analytics run slower here than in a columnar store.
So reach for a graph when the connections are the product.
Why it matters
Fraud rings, recommendations, social graphs, permission chains & network topology.
Neo4j & Amazon Neptune are popular picks.
Pair it with a relational database, which holds the records while the graph holds the links between them.
6. Time-series
A time-series database15 stores measurements stamped with time & organizes them by interval.
Data typically arrives in time order & old measurements rarely change afterward.
Each data point contains a timestamp, a value, and a few tags describing where it came from. New measurements get added to the latest chunk instead of updating old data across the disk,,, this makes writes much faster.
Measurements close together often look similar, so time-series databases can compress them heavily. Also retention rules automatically delete old data, while downsampling replaces detailed data with summaries. i.e., you could keep every measurement for a week, but only hourly averages for a year.
Old data shrinks and/or leaves on a schedule… so database stays within planned size.
Analogy
A ship’s logbook.
Each entry goes on the next line with the time beside it & nobody erases yesterday.
Tradeoff
Time-series databases absorb millions of points a second & answer range queries instantly.
But editing/deleting single points fights the design, so corrections are awkward. Tags with unbounded values, such as a user identifier on every reading, explode the index and exhaust memory16.
So keep tag values few & bounded.
Why it matters
Metrics, sensor readings, prices & anything you plot against time.
InfluxDB, TimescaleDB, and Prometheus lead here.
Pair it with a columnar database, which handles long-term analysis once the raw points are rolled up.
§
Reminder: this is a teaser of the subscriber-only newsletter, exclusive to my golden members.
When you upgrade, you’ll get:
High-level architecture of real-world systems.
Deep dive into how popular real-world systems work.
How real-world systems handle scale, reliability, and performance.
(If this newsletter has helped you become a better software engineer, consider subscribing to support my work.)