The Wrong Way to Pick a Database
Ask a junior engineer what database to use, and you will hear names: "Postgres." "MongoDB." "Redis." "DynamoDB." Ask why, and the answer is usually "that is what we use at work" or "I read a blog post that said it is good."
Ask an AI coding assistant, and you will get the same thing. Names and popularity, not reasoning.
The 7 Building Blocks Framework takes a different approach. Instead of memorizing databases, you learn three storage extremes. Each extreme is great at one thing and sacrifices something else. Once you understand the extremes, you can reason about any database you encounter, even ones that did not exist when you learned the framework.
Three Extremes, Three Tradeoffs
Of the five storage building blocks, three represent fundamental tradeoffs. Think of them as corners of a triangle. Each corner maximizes one property and gives up others.
The Relational Database: Maximum Organization
A relational database stores data in structured tables with defined relationships between them. It can answer complex questions: "Find all orders placed by customers in California who spent more than $500 last quarter, sorted by date."
Strength: Rich queries across related data. You can slice, dice, join, and aggregate in ways that would be painful anywhere else.
Sacrifice: Speed at massive scale. When you need to answer a query in under a millisecond for millions of concurrent users, the overhead of parsing SQL, planning queries, and joining tables adds up. Relational databases are fast. They are not the fastest.
Use when: Your data has relationships that matter. Users have orders. Orders have items. Items have reviews. If you find yourself constantly asking questions that connect different types of data, you want a relational database.
The Key-Value Store: Maximum Speed
A key-value store does one thing: you give it a key, it gives you the value. No queries. No relationships. No joins. Just a lookup.
Strength: Raw speed. A key-value store can return data in microseconds. When Twitter loads your timeline and needs to fetch the display names of 50 users, it is not running 50 SQL queries. It is doing 50 key-value lookups, and they complete faster than a single relational query would.
Sacrifice: Flexibility. You can only retrieve data by its key. You cannot ask "find all users in California." You would need to know every California user's key in advance. There are no relationships, no sorting, no filtering.
Use when: You know exactly what you want and you need it immediately. Session data, cached API responses, user preferences, feature flags. Anything where the access pattern is "give me the thing for this ID."
The File Store: Maximum Capacity
A file store holds large, unstructured data: images, videos, audio files, PDFs, log archives. It does not understand what is inside the files. It just stores bytes and retrieves them.
Strength: Virtually unlimited storage for large objects at a fraction of the cost per gigabyte compared to other storage blocks.
Sacrifice: No organization. A file store is a bucket of files. You cannot query the contents or search across files. You need another system to track metadata.
Use when: You have large blobs of data that do not need to be queried. User-uploaded photos, video files, static assets, backups, machine learning model weights.
The Composition Insight
Here is where the framework gets powerful: most real-world databases are not pure extremes. They are compositions of building blocks.
DynamoDB looks like a key-value store from the outside. But it also supports range queries and secondary indexes. Under the hood, it combines service-like request handling with key-value lookups and some relational query capabilities. It is a composed system.
Cassandra is designed for massive write throughput across distributed nodes. It combines service-like request handling with file-store-like append strategies. Data is written sequentially (like appending to a file) and organized by partition keys (like a key-value store). It sacrifices the rich querying of a relational database but gains enormous write scale.
Redis starts as a pure key-value store but adds data structures: sorted sets, lists, hash maps. It is a key-value store composed with specialized data structure operations.
This is the insight that changes how you evaluate new technology. When someone pitches you a database, do not ask "what is it called?" Ask "what building blocks is it composed of? What extreme does it lean toward? What does it sacrifice?"
| Database | Composition | Optimized For | Sacrifices |
|---|---|---|---|
| PostgreSQL | Relational DB | Complex queries, relationships | Raw speed at extreme scale |
| Redis | Key-Value Store | Sub-millisecond lookups | Query flexibility |
| Amazon S3 | File Store | Unlimited large object storage | Any form of querying |
| DynamoDB | Service + KV Store | Fast lookups with some querying | Complex joins |
| Cassandra | Service + File Store | Massive write throughput | Read flexibility |
The Two Remaining Storage Blocks
Queue
The queue is technically a storage block because it holds data (messages). But its purpose is fundamentally different from the three extremes. A queue is not about storing data for retrieval. It is about buffering work between components. It gets its own article because its role in system resilience deserves a full discussion.
Vector Database
The vector database is the newest building block, driven by the AI era. It stores data as high-dimensional mathematical vectors and retrieves items by similarity rather than exact match.
Where a key-value store answers "give me the item with this exact key" and a relational database answers "give me items matching these conditions," a vector database answers "give me items that feel like this one."
Netflix uses vector similarity to recommend shows. Spotify uses it to build playlists. Search engines use it to understand that a query about "cheap flights to Paris" should match articles about "affordable airfare to France" even though the words are completely different.
Why AI Picks Databases Wrong
When you ask an AI assistant "what database should I use," it recommends something based on pattern matching against its training data. "Most projects like yours use Postgres." That advice is not wrong, exactly. But it is shallow. It picks by name and popularity, not by reasoning.
The building blocks approach asks different questions: What are your access patterns? Do you need relationships? How fast does the response need to be? How large is the data? What are you willing to sacrifice?
Those questions lead to defensible decisions. And when the next database appears (new ones show up every year), you will know how to evaluate it. Not "is this popular?" but "what building blocks is it composed of, and do those tradeoffs fit my system?"
Putting It Together
In practice, most systems use multiple storage blocks. Instagram uses a relational database for user accounts, a key-value store for cached feeds, a file store for photos, and a vector database for recommendations. Each storage block plays to its strength.
The skill is knowing which block handles which data. And that skill comes from understanding the extremes, not memorizing product names.
Ready to practice? The interactive challenges ask you to choose storage blocks for real systems. Next, read about the building block that connects everything together: Queues.