NoSQL
Databases that don't use the relational table model. Includes document (MongoDB), key-value (Redis, DynamoDB), column-family (Cassandra), and graph (Neo4j) databases. NoSQL trades strict schemas for flexibility and horizontal scaling. Chosen when SQL's model doesn't fit.
- Flexible/changing schemas.
- Horizontal scaling needs.
- Specific access patterns (key-value, document, graph).
- Relational data with complex JOINs (use SQL).
- When ACID transactions are essential across items.
Definition
NoSQL databases store data without a fixed table schema. Document stores (MongoDB) use JSON-like documents. Key-value stores (Redis) map keys to values. Column-family (Cassandra) stores wide rows. Graph (Neo4j) stores nodes and edges. Each optimizes for different access patterns.
Why it exists
Relational databases are rigid (fixed schema) and hard to scale horizontally. NoSQL databases offer flexible schemas and horizontal scaling for specific workloads (documents, key-value, time-series, graphs).
How it works
Document: insert/query JSON documents by fields. Key-value: get/set by key (fast). Column-family: partition by row key, sort by column. Graph: traverse nodes/edges. Most have eventual consistency (not ACID by default) for availability and scale.
Scaling limits
Less query power than SQL (no JOINs in many). Eventual consistency can cause stale reads. No transactions across multiple items (usually). Vendor lock-in to specific query APIs.
Cost shape
Self-hosted (free) or managed (MongoDB Atlas, DynamoDB — pay per usage).
Alternatives
- SQL databases — Strict schema, ACID, powerful queries, but rigid.
- NewSQL (CockroachDB, Spanner) — SQL semantics with horizontal scaling.
Failure modes
- Inconsistent data from eventual consistency.
- No JOINs requiring denormalization.
- Vendor lock-in.