api: YAML JSON TOON Database
version: 1.0.0
format: json
dataset:
  id: 40
  slug: nosql-databases-overview
  title: NoSQL Databases Overview
  description: "Document (MongoDB, Couchbase), Key-Value (Redis, DynamoDB), Column-Family (Cassandra, HBase), Graph (Neo4j, JanusGraph). CAP theorem, scaling, use cases."
  summary: "An overview of NoSQL systems by type, data model, consistency, scalability and best uses, with trade-offs and example users. It covers document, key-value, wide-column and graph stores such as MongoDB, Redis, Cassandra, DynamoDB and Neo4j."
  use_when[2]: You are deciding whether a workload fits a non-relational store and which kind.,You need to compare consistency and scaling approaches across NoSQL products.
  caveats[2]: 'NoSQL' is a grouping by what the systems are not; their designs differ more than they share.,"Many NoSQL systems now offer transactions or SQL-like languages, narrowing old distinctions."
  related[4]: database-comparison,cap-theorem,acid-vs-base,graph-databases-comparison
  category: Database Types
  category_slug: database-types
  tags: "nosql,database,mongodb,redis,cassandra,graph,key-value,document"
  view_count: 0
  created_at: 1777673262
  updated_at: 1777673262
  entry_count: 11
  fields[8]{section,field,type,example}:
    databases,name,string,MongoDB
    databases,type,string,Document
    databases,data_model,string,"BSON documents (binary JSON). Flexible schema, …"
    databases,consistency_model,string,Eventual consistency (replica sets); Strong con…
    databases,scalability,string,Horizontal via sharding (range-based or hashed)…
    databases,best_for,string,"Content management, catalogs, user profiles, re…"
    databases,tradeoffs,string,No ACID transactions across documents (until mu…
    databases,example_users,array,"[4 items]"
data:
  databases[11]:
    - name: MongoDB
      type: Document
      data_model: "BSON documents (binary JSON). Flexible schema, nested documents, arrays. Collections hold documents; no joins (embedding or application-side)."
      consistency_model: "Eventual consistency (replica sets); Strong consistency for reads from primary; Tunable consistency (write concern, read preference)."
      scalability: Horizontal via sharding (range-based or hashed). Replica sets for read scaling (secondary reads). Shard key critical for distribution.
      best_for: "Content management, catalogs, user profiles, real-time analytics (with aggregation), mobile apps (flexible schema), JSON-like data."
      tradeoffs: "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."
      example_users[4]: Adobe,eBay,Foursquare,Cisco
    - name: Couchbase
      type: Document
      data_model: JSON documents with integrated cache. Supports N1QL (SQL-like query language for JSON). Buckets (collections) with scopes and collections (v7.0+).
      consistency_model: "Configurable: strong for single document, tunable cross-document via consistency levels. Durable writes to disk and memory."
      scalability: Horizontal scaling via rebalancing; automatic sharding; cross datacenter replication (XDCR) for global distribution.
      best_for: "Interactive web/mobile apps requiring sub-millisecond latency, caching layer + database, session storage, ad-tech, IoT."
      tradeoffs: "More complex than MongoDB, enterprise features require paid license, memory-optimized design increases cost."
      example_users[4]: LinkedIn,PayPal,Toyota,Kroger
    - name: Redis
      type: Key-Value
      data_model: "In-memory key-value store. Values: strings, lists, sets, sorted sets, hashes, streams, hyperloglogs, bitmaps. Keys up to 512MB."
      consistency_model: "Strong consistency (single node); In cluster mode, eventual consistency for some operations. Can configure replication (async) and persistence (RDB/AOF)."
      scalability: Vertical via more memory; Horizontal via Redis Cluster (sharding by hash slot). Read replicas for scaling reads. Cluster requires slots migration on rebalance.
      best_for: "Caching, session storage, leaderboards (sorted sets), pub/sub, real-time analytics, queues (Streams), rate limiting, geospatial (GEO)."
      tradeoffs: "Data must fit in RAM (costly for large datasets), persistence is secondary (in-memory first), cluster setup complex, no complex queries beyond key patterns."
      example_users[4]: Twitter,GitHub,Snapchat,Pinterest
    - name: Amazon DynamoDB
      type: Key-Value / Document
      data_model: "Schema-less items (JSON) in tables. Primary key: partition key (hash) or composite (partition + sort key). Supports secondary indexes (GSI/LSI)."
      consistency_model: Eventually consistent reads (default) or strongly consistent reads (option). ACID transactions across up to 25 items. Multi-region with global tables (last-write-wins).
      scalability: Fully managed automatic scaling. Partitioning based on provisioned throughput (RCU/WCU) or on-demand. No servers to manage.
      best_for: "Serverless applications, high-scale web apps (Amazon's own), session state, shopping carts, gaming leaderboards, IoT time-series."
      tradeoffs: "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."
      example_users[4]: Amazon.com,Netflix,Airbnb,Lyft
    - name: Cassandra
      type: Column-Family
      data_model: Wide-column store. Tables with rows and columns; columns can vary per row. Partition key determines distribution; clustering keys order within partition.
      consistency_model: "Tunable consistency per operation (ONE, QUORUM, ALL). Eventually consistent by default; can achieve strong consistency with QUORUM reads/writes."
      scalability: Linear horizontal scalability; peer-to-peer (no master); adds nodes without downtime. Designed for multi-datacenter replication (async).
      best_for: "Time-series data, messaging (write-heavy), IoT sensor data, recommendation engines, write-intensive workloads, multi-region deployments."
      tradeoffs: "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)."
      example_users[4]: Apple (iMessage),Netflix (recommendations),Uber,Instagram
    - name: Apache HBase
      type: Column-Family
      data_model: Hadoop-compatible wide-column store. Inspired by Google Bigtable. Sorted by row key; sparse rows (columns vary per row). Versioned cells.
      consistency_model: Strong consistency per row (single region server). Weak consistency across regions (async replication).
      scalability: Scales horizontally on HDFS; region servers split when hot; automatic sharding. Designed for thousands of nodes.
      best_for: "Big data analytics on Hadoop, sparse datasets, random real-time read/write access to huge tables (billions rows), time-series at extreme scale."
      tradeoffs: "Tightly coupled to Hadoop ecosystem (HDFS), operational complexity, latency higher than Cassandra (HDFS commit log), not ideal for OLTP."
      example_users[4]: Facebook (messaging),Yahoo!,Pinterest,Twitter (some analytics)
    - name: Neo4j
      type: Graph (Property Graph)
      data_model: "Property graph: Nodes (entities) with labels, Relationships (edges) with types and directions, Properties (key-value) on both. Native graph storage (not relational)."
      consistency_model: "ACID-compliant transactions (full). Strong consistency within a cluster (Causal consistency in causal cluster, full ACID in single-instance or HA cluster)."
      scalability: Single-instance scales vertically; Causal cluster for HA (read replicas); Neo4j Fabric for sharding across multiple databases; Neo4j Aura for managed cloud scaling.
      best_for: "Social networks, fraud detection (pattern matching), knowledge graphs, recommendation engines (people who bought X also bought Y), network/IT operations."
      tradeoffs: "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."
      example_users[4]: Walmart,NASA,HP,Airbnb
    - name: Amazon Neptune
      type: Graph (Property Graph + RDF)
      data_model: "Supports both property graph (Gremlin) and RDF (SPARQL). Fully managed AWS service. ACID transactions, high availability."
      consistency_model: Strong consistency for reads in same region. Multi-region replication with eventual consistency. ACID within single region cluster.
      scalability: Serverless or provisioned capacity; auto-scaling; read replicas; stored on SSD for low-latency graph traversals.
      best_for: "Knowledge graphs, fraud rings, social networks, recommendation engines, drug discovery, integrated AWS ecosystem users."
      tradeoffs: "Vendor lock-in (AWS), Gremlin learning curve, limited to Neptune's feature subset vs open-source alternatives, cost can escalate with data size."
      example_users[4]: Amazon (product catalog),Siemens,T-Mobile,Nasdaq
    - name: Apache JanusGraph
      type: Graph (Property Graph)
      data_model: "Distributed graph database. Supports property graph model (Gremlin traversal language). Pluggable storage backends (Cassandra, HBase, ScyllaDB) and indexing (Elasticsearch, Solr)."
      consistency_model: Eventual consistency (depends on storage backend). Supports ACID for single transaction within a partition.
      scalability: Massive horizontal scalability via storage backend (Cassandra/HBase). Can handle billions of vertices/edges across cluster.
      best_for: "Large-scale graph analytics, fraud detection at scale, knowledge graphs with billions of edges, use cases requiring Gremlin."
      tradeoffs: "Operational complexity (manages Cassandra/HBase cluster), eventual consistency, slower query times vs Neo4j for small-medium graphs, less mature tooling."
      example_users[3]: IBM (Watson),Grail (security analytics),CERN (data preservation)
    - name: RedisGraph
      type: Graph (Property Graph)
      data_model: Graph module for Redis. Stores graph as sparse adjacency matrix. Query via Cypher (Neo4j-like). Native graph processing with matrix multiplication on GPU (experimental).
      consistency_model: Strong consistency (single Redis node or Redis Enterprise). ACID transactions within Redis transaction block.
      scalability: Limited to single Redis cluster shard; best for graphs that fit within Redis cluster memory. Redis Enterprise supports active-active geo-distribution.
      best_for: "Low-latency graph queries alongside cached data, recommendation engines in caching layer, fraud detection with sub-ms response."
      tradeoffs: "Graph must fit in memory (like Redis), query capabilities subset of full graph DBs, cluster mode graph queries limited to single shard."
      example_users[3]: Shopify,Verizon,Vodafone
    - name: ArangoDB
      type: Multi-Model (Document + Graph + Key-Value)
      data_model: "Unified multi-model database. Documents (JSON), Graphs (edge collections), Key-Value. AQL query language supports joins across models."
      consistency_model: Strong consistency (single server); Tunable in cluster (quorum). ACID transactions for single document; multi-document transactions in cluster (experimental).
      scalability: Horizontal via sharding (smart or hash); SmartGraphs for localized queries; replication for HA.
      best_for: "Applications needing multiple data models (graph + documents), flexible schema evolution, use cases combining relational joins and graph traversals."
      tradeoffs: "Jack of all trades, master of none (graph queries slower than Neo4j, document features vs MongoDB), cluster complexity, less mature ecosystem per model."
      example_users[4]: Adobe,Siemens,Cisco,Coursera