NoSQL Comparison
NoSQL Type Comparison
| Database | Type | Data Model | Best For | Consistency |
|---|---|---|---|---|
| MongoDB | Document | JSON/BSON documents | Flexible schemas, general-purpose | Strong (replica set) / Eventual |
| Redis | Key-Value / In-Memory | Strings, Hashes, Lists, Sets, ZSets | Cache, sessions, leaderboards, pub/sub | Strong (single) / Eventual (cluster) |
| Apache Cassandra | Wide Column | Tables with partition + clustering keys | Time-series, write-heavy, global scale | Tunable (ONE to ALL) |
| Amazon DynamoDB | Key-Value + Document | Items with PK (+ optional SK) | Serverless, predictable latency at scale | Eventual / Strong (option) |
| ClickHouse | Columnar OLAP | Columns, materialized views | Analytics, aggregations, log analysis | Eventual |
| Neo4j | Graph | Nodes + Edges + Properties | Relationships, fraud detection, recommendations | Strong (ACID) |
| InfluxDB | Time Series | Measurements, tags, fields, timestamps | Metrics, IoT, monitoring data | Eventual |
CAP Theorem in Practice
| Category | Guarantees | Examples | Tradeoff |
|---|---|---|---|
| CP (Consistent + Partition-tolerant) | Data is always consistent; may reject writes during partition | MongoDB (w:majority), HBase, Zookeeper | Availability drops during network partition |
| AP (Available + Partition-tolerant) | Always responds, but may return stale data | Cassandra, DynamoDB, CouchDB | Reads may be stale; eventual consistency |
| CA (Consistent + Available) | Consistent and available โ no partition tolerance | Traditional RDBMS (single node) | Cannot scale horizontally across network |
Selection Guide
Choose MongoDB when:
โ Flexible / evolving schema
โ Rich document queries needed
โ General-purpose application database
โ High write throughput at global scale (use Cassandra)
Choose Redis when:
โ Sub-millisecond latency required
โ Caching, rate limiting, sessions, pub/sub
โ Durability is critical (data in memory)
Choose Cassandra when:
โ Billions of rows, multi-region writes
โ Time-series or append-heavy workloads
โ Complex queries, joins (model around queries)
Choose DynamoDB when:
โ AWS-native, serverless, auto-scaling
โ Single-digit millisecond latency at any scale
โ Complex queries (requires careful data modeling)
Choose ClickHouse when:
โ Analytical queries on billions of rows
โ Real-time aggregations, dashboards
โ OLTP workloads (low-latency writes per row)