System Design: NoSQL Database Types
Explore NoSQL database paradigms including Key-Value, Document, Column-Family, Graph, and Time-Series engines, SQL vs NoSQL decision frameworks, and Polyglot Persistence.
1. NoSQL Database Paradigms Overview
NoSQL (Not Only SQL) databases were designed to address the horizontal scaling limitations, rigid schema constraints, and high latency of traditional relational databases under massive web scale. Different NoSQL database families organize data differently depending on read and write requirements.
NoSQL Database Taxonomy & Structural Storage Models
System DesignComparing structural organization across Key-Value, Document, Wide-Column, Graph, and Time-Series databases
2. Key-Value & Document Stores
Key-Value Stores (Redis, DynamoDB)
Stores data as an arbitrary string or binary blob paired with a unique key string. Operates like a massive distributed hash table offering sub-millisecond O(1) point lookups.
- Use Cases:Session management, caching, rate limiting, shopping carts.
- Limitation:Queries cannot filter by values inside the stored blob without fetching the full key.
Document Stores (MongoDB, Couchbase)
Stores data as semi-structured JSON or BSON documents. Supports nested arrays, embedded objects, and flexible schemas that evolve without table alter migrations.
- Use Cases:E-commerce product catalogs, user profiles, content management systems.
- Limitation:Complex multi-document transactions incur performance overhead compared to relational engines.
3. Column-Family Stores & Graph Databases
Column-Family Stores (Apache Cassandra, HBase)
Organizes data in rows containing dynamic, sparse column families. Writes are appended sequentially to commit logs and SSTables, enabling massive horizontal scale across hundreds of database nodes.
- Use Cases:Write-heavy IoT telemetry, financial ledger logs, messaging message stores.
- Limitation:Queries must strictly follow the pre-defined partition key and clustering key design.
Graph Databases (Neo4j, Amazon Neptune)
Stores entities as Nodes and relationships as Edges with associated key-value properties. Navigates deeply nested relationships in O(1) pointer-hopping time without expensive relational SQL JOIN operations.
- Use Cases:Social networks, recommendation engines, fraud detection networks, knowledge graphs.
- Limitation:Difficult to partition across multiple shards horizontally due to interconnected graph pointer edges.
4. Time-Series Databases
Time-Series databases (InfluxDB, TimescaleDB) are optimized specifically for handling sequence data indexed by timestamps. They feature automated data compression, time-window aggregations, and continuous downsampling policies.
Time-Series Architecture Capabilities
- High Append Rate:Optimized for non-stop append-only write streams from millions of infrastructure agents or sensors.
- Automated Downsampling:Automatically aggregates per-second raw metrics into hourly averages after 30 days to save disk space.
- Use Cases:Application monitoring (APM), server metrics, stock market tick data, weather telemetry.
5. Choosing SQL vs NoSQL
Selecting between SQL relational databases and NoSQL database engines depends on data structure predictability, consistency requirements, and scaling dimensions.
Choose Relational SQL (PostgreSQL, MySQL) When:
- ACID Compliance:Requires strict transactional guarantees (e.g. banking balances, order checkouts).
- Structured Schema:Data entities have highly structured relationships requiring multi-table JOINs and foreign keys.
- Scale Pattern:Traffic fits on single primary machines supplemented by read replicas.
Choose NoSQL (MongoDB, Cassandra, Redis) When:
- Horizontal Scale:Data volume or write throughput exceeds single-node hardware boundaries and requires sharding.
- Unstructured/Fluid Data:Attributes vary significantly across records or change frequently without schema migrations.
- Specialized Workloads:Requires sub-millisecond key lookups (Redis), graph traversals (Neo4j), or time metrics (InfluxDB).
6. Polyglot Persistence
Modern microservice architectures rarely force a single database technology on the entire application stack. Polyglot Persistence describes selecting different database technologies for different microservices based on each domain's distinct workload requirements.
Polyglot Persistence Microservice Architecture
System DesignRouting distinct service domains to dedicated database engines tailored for their specific access patterns
Review how the Node.js service manager below interacts with PostgreSQL, Redis, and MongoDB within a unified application codebase.
Polyglot Persistence Application Integration
Coordinating relational transactions, in-memory caching, and document store queries in Node.js
Press Run to execute the code and see output here.
Compare query semantics across MongoDB document queries, Cassandra CQL partition queries, and Neo4j Cypher graph traversals below.
Query Language Syntax Comparison Across NoSQL Paradigms
Comparing MongoDB document filtering, Cassandra CQL column queries, and Neo4j Cypher graph traversals
Press Run to execute the code and see output here.
NoSQL Database Types Knowledge Verification
1. What defines a Key-Value database store like Redis or DynamoDB?
2. Which use case is best suited for Document stores like MongoDB?
3. What makes Column-Family stores (Cassandra) effective for heavy writes?
4. What is the primary advantage of Graph databases like Neo4j?
5. What is Polyglot Persistence in system design?