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)