NoSQL Databases: Flexibility at Scale
"NoSQL" doesn't mean "no SQL" — it means "not only SQL." These databases sacrifice some of the guarantees relational databases provide in exchange for flexibility, horizontal scalability, and optimization for specific access patterns.
The Four Types of NoSQL
Why NoSQL?
Three Driving Forces
- Flexible schema — Your data structure evolves rapidly, or different records have different fields. No migrations needed.
- Horizontal scaling — Distribute data across dozens or hundreds of nodes. Write throughput scales linearly.
- Specific access patterns — When you always access data the same way (by key, by time range, by graph traversal), a specialized store is 10-100x faster than a general-purpose SQL query.
The Trade-Off: CAP Theorem in Practice
Most NoSQL databases sacrifice some aspect of ACID to achieve availability and partition tolerance:
| SQL (ACID) | NoSQL (BASE) |
|---|---|
| Strong consistency | Basically Available |
| Immediate | Soft state (may change without input) |
| Always current | Eventually consistent |
This doesn't mean NoSQL has no guarantees — it means you trade strict consistency for availability. When a network partition occurs, the system stays up but different nodes may briefly disagree.
When to Use Each Type
| Type | Best For | Avoid When |
|---|---|---|
| Document | Varied schemas, content management, user profiles, catalogs | You need complex joins or transactions across documents |
| Key-Value | Session storage, caching, rate limiting, real-time leaderboards | You need to query by anything other than the key |
| Column-Family | Time-series, IoT data, analytics, high-write-volume logging | You need ad-hoc queries or complex aggregations |
| Graph | Social networks, recommendation engines, fraud detection, routing | Your data doesn't have meaningful relationships to traverse |
SQL vs NoSQL Comparison
| Dimension | SQL | NoSQL |
|---|---|---|
| Schema | Fixed, enforced | Flexible, schema-on-read |
| Scaling | Primarily vertical | Designed for horizontal |
| Consistency | Strong (ACID) | Tunable (eventual to strong) |
| Query language | SQL (standardized) | Varies per database |
| Joins | Native, efficient | Usually not supported / application-level |
| Transactions | Multi-table ACID | Usually single-document/key |
| Best for | Complex relationships, integrity | Scale, speed, specific patterns |
Netflix: Cassandra for Global Availability
Netflix uses Apache Cassandra to store viewing history, bookmarks, and activity data across multiple AWS regions. Why Cassandra?
- No single point of failure — Every node is equal (no leader). Any node can accept writes.
- Multi-region replication — Data written in US-East is automatically replicated to EU-West. Users get low-latency reads from the nearest datacenter.
- Write-optimized — Viewing events stream in at millions per second. Cassandra's log-structured storage handles this effortlessly.
- Eventual consistency is acceptable — If your "Continue Watching" list is 2 seconds stale, you won't notice.
Uber: Graph Databases for Trip Routing
Uber uses graph databases to model road networks and optimize routing:
- Nodes represent intersections, edges represent road segments with properties (speed limit, traffic, distance)
- Graph traversal finds shortest paths considering real-time traffic conditions
- Why not SQL? — Finding the fastest route through a road network requires traversing potentially thousands of connected nodes. A graph database does this in milliseconds; SQL would need dozens of self-joins.
Interactive: Pick the Right Database
Read the use case and select the best database type. Think about the data shape and access patterns.