Data Storage

6 min read

The Most Consequential Decision in Most Designs

If there's one choice that shapes everything else in your system, it's where and how you store data. The database you pick determines your query patterns, your consistency guarantees, your scaling strategy, and often your operational burden for years to come. Choose a relational database for a problem that needs flexible schemas, and you'll fight migrations forever. Choose a NoSQL database for a problem that needs joins and transactions, and you'll re-implement half of SQL in application code.

The right approach is to let access patterns drive the decision, not familiarity. Ask: What queries will be hot? What's the read/write ratio? How much data will there be? Do I need joins? Do I need transactions? How important is consistency vs latency? The answers map directly to a database family.

When This Comes Up

System design interviews: "What database would you use?" is asked in every interview. The answer is never just a name — it's a name plus a justification based on access patterns, consistency needs, and scale requirements.
Real-world architecture: Database choice is one of the hardest decisions to reverse. A migration from MongoDB to PostgreSQL (or vice versa) is a multi-quarter project. Getting it right the first time saves enormous pain.
Polyglot persistence: Modern systems often use multiple databases — SQL for transactional data, Redis for caching, Elasticsearch for search, S3 for media. Knowing which tool fits which job is the skill.

The Landscape at a Glance

The storage world splits into three major categories, each with specialists:

Category	Optimized For	Examples
SQL / RDBMS	Relationships, joins, ACID transactions	PostgreSQL, MySQL
NoSQL	Scale, flexibility, specific access patterns	Redis, MongoDB, Cassandra, Neo4j
NewSQL	SQL semantics + horizontal scaling	CockroachDB, Google Spanner, TiDB
Specialists	Specific data shapes (time-series, graphs, blobs)	InfluxDB, Neo4j, S3

The NoSQL family itself contains four distinct shapes — key-value, document, wide-column, and graph — each optimized for a completely different access pattern. Knowing which one to reach for is more important than knowing the API of any specific product.

How the Sub-Topics Connect

The sub-topics below are ordered from the most general-purpose to the most specialized:

1. SQL Databases (RDBMS)

The default choice for structured data with relationships. SQL databases give you rigid schemas, joins, and ACID transactions — critical when correctness is non-negotiable (money, inventory, user accounts). PostgreSQL and MySQL handle far more scale than most people assume (millions of rows, thousands of QPS) before you need to look beyond them. Start here unless you have a specific reason not to.

2. NoSQL Databases

An overview of why NoSQL exists and when to choose it over SQL. NoSQL isn't one thing — it's four families trading different parts of the SQL contract for scale, flexibility, or performance. This sub-topic covers the common thread: schema flexibility, horizontal scaling, and the trade-offs you accept (no joins, weaker consistency, query pattern lock-in).

3. NewSQL

The attempt to get the best of both worlds: SQL semantics and distributed transactions on horizontally scalable storage. CockroachDB, Google Spanner, and TiDB deliver on this promise — at the cost of higher write latency (consensus rounds) and operational complexity. When you need relational guarantees at global scale, NewSQL is the answer.

4–7. The NoSQL Families

Each NoSQL family is optimized for a specific data shape and access pattern:

Sub-Topic	Data Shape	Best For	Worst For
Key-Value Stores	Simple key → value pairs	Caching, sessions, counters, config	Ad-hoc queries, relationships
Document Stores	Semi-structured JSON documents	Content, user profiles, catalogs	Joins, cross-document transactions
Wide-Column Stores	Sparse columns, row-key partitioned	High-write time-series, IoT, logs	Ad-hoc queries, joins
Graph Databases	Nodes and edges	Social graphs, recommendations, fraud detection	Bulk analytics, non-graph queries

The key insight: you model the table around the query in NoSQL, whereas in SQL you model the data and let the query language handle the rest. This is why choosing the wrong NoSQL family is more painful than choosing the wrong SQL database.

8–9. Specialist Databases

Sub-Topic	Niche	Why It Exists
Time-Series Databases	Append-only metrics queried by time range	Extreme compression and fast range scans for monitoring, IoT
In-Memory Databases	Working set in RAM	Microsecond latency for caching, sessions, leaderboards

10–11. File and Object Storage

Not everything belongs in a database. Large, immutable files — images, videos, backups, logs — belong in storage systems designed for blobs:

Sub-Topic	Interface	Best For
Object Storage	HTTP (key-based, immutable)	User uploads, media, backups, data lakes — the default for blobs
File Storage	POSIX filesystem (NFS, EFS)	Legacy apps that expect a mounted path — scales poorly compared to object storage

Sub-Topics

#	Sub-Topic	What You'll Learn
1	SQL Databases (RDBMS)	When relational is the right default — schemas, joins, ACID
2	NoSQL Databases	Why NoSQL exists and the four families at a glance
3	NewSQL	SQL semantics + horizontal scaling — Spanner, CockroachDB, TiDB
4	Key-Value Stores	O(1) lookups — Redis, DynamoDB for caching and sessions
5	Document Stores	Semi-structured JSON — MongoDB for self-contained records
6	Wide-Column Stores	High write throughput — Cassandra, HBase for time-series and IoT
7	Graph Databases	Traversal-optimized — Neo4j for social graphs and recommendations
8	Time-Series Databases	Append-only metrics — InfluxDB, Prometheus for monitoring
9	In-Memory Databases	RAM-speed access — Redis, Memcached for microsecond latency
10	Object Storage	Immutable blobs at unlimited scale — S3, GCS
11	File Storage	POSIX filesystem — NFS, EFS for legacy compatibility