api: YAML JSON TOON Database
version: 1.0.0
format: yaml
dataset:
  id: 2862
  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:
    - 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:
    - "'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:
    - database-comparison
    - cap-theorem
    - acid-vs-base
    - graph-databases-comparison
  entry_count: 11
  fields:
    - section: databases
      field: name
      type: string
      example: MongoDB
    - section: databases
      field: type
      type: string
      example: Document
    - section: databases
      field: data_model
      type: string
      example: BSON documents (binary JSON). Flexible schema, …
    - section: databases
      field: consistency_model
      type: string
      example: Eventual consistency (replica sets); Strong con…
    - section: databases
      field: scalability
      type: string
      example: Horizontal via sharding (range-based or hashed)…
    - section: databases
      field: best_for
      type: string
      example: Content management, catalogs, user profiles, re…
    - section: databases
      field: tradeoffs
      type: string
      example: No ACID transactions across documents (until mu…
    - section: databases
      field: example_users
      type: array
      example: "[4 items]"
  category: Database Types
  category_slug: database-types
  tags: nosql,database,mongodb,redis,cassandra,graph,key-value,document
  view_count: 65
  created_at: 1777673262
  updated_at: 1777673262
data:
  databases:
    - 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:
        - 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:
        - 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:
        - 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:
        - 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:
        - 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:
        - 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:
        - 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:
        - 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:
        - 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:
        - 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:
        - Adobe
        - Siemens
        - Cisco
        - Coursera