NoSQL Databases Overview
Document (MongoDB, Couchbase), Key-Value (Redis, DynamoDB), Column-Family (Cassandra, HBase), Graph (Neo4j, JanusGraph). CAP theorem, scaling, use cases.
Document (MongoDB, Couchbase), Key-Value (Redis, DynamoDB), Column-Family (Cassandra, HBase), Graph (Neo4j, JanusGraph). CAP theorem, scaling, use cases.
| Name | Type | Data model | Consistency model | Scalability | Best for | Tradeoffs | Example users |
|---|---|---|---|---|---|---|---|
| MongoDB | Document | BSON documents (binary JSON). Flexible schema, nested documents, arrays. Collections hold documents; no joins (embedding or application-side). | Eventual consistency (replica sets); Strong consistency for reads from primary; Tunable consistency (write concern, read preference). | Horizontal via sharding (range-based or hashed). Replica sets for read scaling (secondary reads). Shard key critical for distribution. | Content management, catalogs, user profiles, real-time analytics (with aggregation), mobile apps (flexible schema), JSON-like data. | No ACID transactions across documents (until multi-document in v4.0+ but limited), no joins (denormalization required), memory usage high for indexes, eventual consistency in distributed setup. |
|
| Couchbase | Document | JSON documents with integrated cache. Supports N1QL (SQL-like query language for JSON). Buckets (collections) with scopes and collections (v7.0+). | Configurable: strong for single document, tunable cross-document via consistency levels. Durable writes to disk and memory. | Horizontal scaling via rebalancing; automatic sharding; cross datacenter replication (XDCR) for global distribution. | Interactive web/mobile apps requiring sub-millisecond latency, caching layer + database, session storage, ad-tech, IoT. | More complex than MongoDB, enterprise features require paid license, memory-optimized design increases cost. |
|
| Redis | Key-Value | In-memory key-value store. Values: strings, lists, sets, sorted sets, hashes, streams, hyperloglogs, bitmaps. Keys up to 512MB. | Strong consistency (single node); In cluster mode, eventual consistency for some operations. Can configure replication (async) and persistence (RDB/AOF). | Vertical via more memory; Horizontal via Redis Cluster (sharding by hash slot). Read replicas for scaling reads. Cluster requires slots migration on rebalance. | Caching, session storage, leaderboards (sorted sets), pub/sub, real-time analytics, queues (Streams), rate limiting, geospatial (GEO). | Data must fit in RAM (costly for large datasets), persistence is secondary (in-memory first), cluster setup complex, no complex queries beyond key patterns. |
|
| Amazon DynamoDB | Key-Value / Document | Schema-less items (JSON) in tables. Primary key: partition key (hash) or composite (partition + sort key). Supports secondary indexes (GSI/LSI). | Eventually consistent reads (default) or strongly consistent reads (option). ACID transactions across up to 25 items. Multi-region with global tables (last-write-wins). | Fully managed automatic scaling. Partitioning based on provisioned throughput (RCU/WCU) or on-demand. No servers to manage. | Serverless applications, high-scale web apps (Amazon's own), session state, shopping carts, gaming leaderboards, IoT time-series. | Vendor lock-in (AWS), expensive at scale (pay per request/throughput), limited query capabilities (no joins), partition key design critical for distribution, single-digit ms latency but variable. |
|
| Cassandra | Column-Family | Wide-column store. Tables with rows and columns; columns can vary per row. Partition key determines distribution; clustering keys order within partition. | Tunable consistency per operation (ONE, QUORUM, ALL). Eventually consistent by default; can achieve strong consistency with QUORUM reads/writes. | Linear horizontal scalability; peer-to-peer (no master); adds nodes without downtime. Designed for multi-datacenter replication (async). | Time-series data, messaging (write-heavy), IoT sensor data, recommendation engines, write-intensive workloads, multi-region deployments. | No joins or aggregations (must be done client-side), limited secondary indexes, no transactions across partitions (lightweight transactions via LWT), requires careful data modeling (query-first). |
|
| Apache HBase | Column-Family | Hadoop-compatible wide-column store. Inspired by Google Bigtable. Sorted by row key; sparse rows (columns vary per row). Versioned cells. | Strong consistency per row (single region server). Weak consistency across regions (async replication). | Scales horizontally on HDFS; region servers split when hot; automatic sharding. Designed for thousands of nodes. | Big data analytics on Hadoop, sparse datasets, random real-time read/write access to huge tables (billions rows), time-series at extreme scale. | Tightly coupled to Hadoop ecosystem (HDFS), operational complexity, latency higher than Cassandra (HDFS commit log), not ideal for OLTP. |
|
| Neo4j | Graph (Property Graph) | Property graph: Nodes (entities) with labels, Relationships (edges) with types and directions, Properties (key-value) on both. Native graph storage (not relational). | ACID-compliant transactions (full). Strong consistency within a cluster (Causal consistency in causal cluster, full ACID in single-instance or HA cluster). | Single-instance scales vertically; Causal cluster for HA (read replicas); Neo4j Fabric for sharding across multiple databases; Neo4j Aura for managed cloud scaling. | Social networks, fraud detection (pattern matching), knowledge graphs, recommendation engines (people who bought X also bought Y), network/IT operations. | Not ideal for analytical queries on entire graph (beyond 3-4 hops), licensing costs for enterprise features (cluster, causal consistency), graph queries require different mindset. |
|
| Amazon Neptune | Graph (Property Graph + RDF) | Supports both property graph (Gremlin) and RDF (SPARQL). Fully managed AWS service. ACID transactions, high availability. | Strong consistency for reads in same region. Multi-region replication with eventual consistency. ACID within single region cluster. | Serverless or provisioned capacity; auto-scaling; read replicas; stored on SSD for low-latency graph traversals. | Knowledge graphs, fraud rings, social networks, recommendation engines, drug discovery, integrated AWS ecosystem users. | Vendor lock-in (AWS), Gremlin learning curve, limited to Neptune's feature subset vs open-source alternatives, cost can escalate with data size. |
|
| Apache JanusGraph | Graph (Property Graph) | Distributed graph database. Supports property graph model (Gremlin traversal language). Pluggable storage backends (Cassandra, HBase, ScyllaDB) and indexing (Elasticsearch, Solr). | Eventual consistency (depends on storage backend). Supports ACID for single transaction within a partition. | Massive horizontal scalability via storage backend (Cassandra/HBase). Can handle billions of vertices/edges across cluster. | Large-scale graph analytics, fraud detection at scale, knowledge graphs with billions of edges, use cases requiring Gremlin. | Operational complexity (manages Cassandra/HBase cluster), eventual consistency, slower query times vs Neo4j for small-medium graphs, less mature tooling. |
|
| RedisGraph | Graph (Property Graph) | Graph module for Redis. Stores graph as sparse adjacency matrix. Query via Cypher (Neo4j-like). Native graph processing with matrix multiplication on GPU (experimental). | Strong consistency (single Redis node or Redis Enterprise). ACID transactions within Redis transaction block. | Limited to single Redis cluster shard; best for graphs that fit within Redis cluster memory. Redis Enterprise supports active-active geo-distribution. | Low-latency graph queries alongside cached data, recommendation engines in caching layer, fraud detection with sub-ms response. | Graph must fit in memory (like Redis), query capabilities subset of full graph DBs, cluster mode graph queries limited to single shard. |
|
| ArangoDB | Multi-Model (Document + Graph + Key-Value) | Unified multi-model database. Documents (JSON), Graphs (edge collections), Key-Value. AQL query language supports joins across models. | Strong consistency (single server); Tunable in cluster (quorum). ACID transactions for single document; multi-document transactions in cluster (experimental). | Horizontal via sharding (smart or hash); SmartGraphs for localized queries; replication for HA. | Applications needing multiple data models (graph + documents), flexible schema evolution, use cases combining relational joins and graph traversals. | Jack of all trades, master of none (graph queries slower than Neo4j, document features vs MongoDB), cluster complexity, less mature ecosystem per model. |
|
The static files are identical to what the API returns, but with no rate limit and no server round trip. Use the API when you want a query and a content type; use the files when you want to cache one document.
curl "https://yjtoon.com/api/dataset/nosql-databases-overview?format=toon"
const res = await fetch( "https://yjtoon.com/static-data/dataset/nosql-databases-overview.toon" ); const toon = await res.text();
Rate limit: 120 requests per minute per IP, no key and no signup. API reference →