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 Design

Comparing structural organization across Key-Value, Document, Wide-Column, Graph, and Time-Series databases

100%
Loading system design canvas…

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 Design

Routing distinct service domains to dedicated database engines tailored for their specific access patterns

100%
Loading system design canvas…

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

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

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?