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."
  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
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"