{ "api": "YAML JSON TOON Database", "version": "1.0.0", "format": "json", "dataset": { "id": 356, "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": 5, "created_at": 1781275786, "updated_at": 1781275786 }, "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" ] } ] } }