This page is for architects and developers choosing a database for workloads that a single relational server handles poorly: very high write rates, flexible or nested data, relationship-heavy queries, global distribution or sub-millisecond lookups. It lists two different families and keeps them apart. NoSQL systems use a non-relational data model and their own query APIs: document databases (MongoDB, Couchbase, Apache CouchDB, RavenDB), key-value stores (Amazon DynamoDB, FoundationDB, Aerospike), wide-column stores (Apache Cassandra, ScyllaDB, Apache HBase, Bigtable), graph databases (Neo4j), multimodel databases (ArangoDB, OrientDB, Azure Cosmos DB) and in-memory systems (Redis, Apache Ignite).
Distributed SQL databases are relational: tables, SQL, joins and serializable or strongly consistent transactions, with data split and replicated across nodes by consensus. The listings are CockroachDB and YugabyteDB (both PostgreSQL-compatible to different degrees), TiDB (MySQL-compatible) and the PostgreSQL extension Citus. Licensing has moved in several products: ScyllaDB and ArangoDB are no longer open source, the free CockroachDB Core licence ended with v24.3, MongoDB Community Server is under the SSPL, and Redis 8 is offered under RSALv2, SSPLv1 or AGPLv3.
What this software does
Every product here scales by partitioning data across nodes on a key: a shard key in MongoDB, a partition key hashed onto a token ring in Cassandra, a partition key in DynamoDB, row-key ranges in HBase and Bigtable, or automatic ranges and tablets in CockroachDB, YugabyteDB and TiDB. Each partition is replicated for availability. Replication follows one of two broad designs: a primary per partition with followers (MongoDB replica sets, and Raft consensus groups in distributed SQL), or masterless replication where any replica accepts writes (Cassandra, ScyllaDB). The design sets the consistency you get. Cassandra is tunable per request, eventual by default and strong with quorum reads and writes; DynamoDB reads are eventually consistent unless you request strong reads; distributed SQL databases are strongly consistent by default.
NoSQL systems give up some relational features to scale or to fit a data shape. Queries are designed around keys and access patterns, often without joins: Cassandra tables are modelled per query, and DynamoDB queries must follow the key design. Transaction scope is usually narrower: Cassandra and ScyllaDB offer single-partition lightweight transactions, HBase and Bigtable are atomic per row, DynamoDB transactions are limited to 100 actions in one Region, and FoundationDB offers full ACID but limits transactions to five seconds and 10 MB. Each family also has its own query language, such as the MongoDB Query API, CQL, SQL++ (Couchbase), Cypher (Neo4j), AQL (ArangoDB) and RQL (RavenDB).
Distributed SQL takes the opposite trade: it keeps the relational model and multi-row ACID transactions across nodes, using consensus replication (Raft in CockroachDB, YugabyteDB and TiDB) so that a node or zone can fail without manual failover. The cost is extra latency for distributed transactions and the need for applications to retry on serialization conflicts. Compatibility is a key buying point: YugabyteDB reuses the PostgreSQL query layer, CockroachDB speaks the PostgreSQL wire protocol but is not a drop-in replacement, TiDB targets MySQL 8.0 compatibility, and Citus is PostgreSQL itself with sharding added.
Types of product in this category
- Document: Stores JSON or BSON documents with nested fields and flexible schemas, queried by field and index (MongoDB, Couchbase, Apache CouchDB, RavenDB).
- Key-value: Addresses each item by a key for very fast reads and writes, with limited querying beyond the key (Amazon DynamoDB, FoundationDB, Aerospike).
- Wide-column: Stores rows by partition or row key with many columns grouped in families or clustering columns, built for very large, write-heavy datasets (Apache Cassandra, ScyllaDB, Apache HBase, Bigtable).
- Graph: Stores nodes and relationships as first-class data and queries paths through them, here with Cypher in Neo4j.
- Multimodel: Supports several data models, such as document, graph and key-value, in one engine or service (ArangoDB, OrientDB, and Azure Cosmos DB with its NoSQL, MongoDB, Cassandra, Gremlin and Table APIs).
- In-memory: Keeps the working dataset in RAM for very low latency, used for caching, sessions, queues and real-time data (Redis, Apache Ignite).
- Distributed SQL: Relational databases that shard and replicate automatically while keeping SQL and distributed ACID transactions (CockroachDB, YugabyteDB, TiDB, and the Citus extension for PostgreSQL).
Typical use cases
High-volume writes: telemetry, events and logs
Wide-column stores such as Cassandra and ScyllaDB accept writes on any replica and scale by adding nodes, which suits sensor readings, activity feeds and audit events keyed by device or user and time.
Flexible product catalogues and user profiles
Document databases such as MongoDB and Couchbase store records whose fields vary between items, without schema migrations for every new attribute.
Caching, sessions and real-time counters
In-memory stores such as Redis hold sessions, rate limits, leaderboards and queues where sub-millisecond latency matters more than durability of every write.
Relationship-heavy queries
Fraud rings, recommendations, network topology and access graphs are simpler to express as graph traversals in Neo4j or ArangoDB than as many SQL joins.
Global OLTP that must stay relational
Order, payment and account systems that need SQL and strong consistency across zones or regions are the target of CockroachDB, YugabyteDB and TiDB, and of Google Cloud Spanner outside this list.
Offline-first mobile and edge sync
Apache CouchDB with PouchDB and Couchbase with Couchbase Lite replicate data to browsers and devices and sync it back when they reconnect.
How to choose
- Data model and access patterns. Start from the queries, not the product. List the reads and writes the application performs and their volumes, then choose the model that serves them directly. Key-value and wide-column stores need every major query known in advance; document databases tolerate more ad hoc querying; relational distributed SQL handles changing query patterns best.
- Consistency and transaction scope. Check what is atomic and what a read is guaranteed to see. Compare single-partition lightweight transactions (Cassandra, ScyllaDB), single-row atomicity (HBase, Bigtable), bounded multi-item transactions (DynamoDB, 100 actions), multi-document ACID transactions (MongoDB, Couchbase) and fully distributed ACID (CockroachDB, YugabyteDB, TiDB). Some features are edition-gated: Aerospike strong consistency and transactions need Enterprise licensing.
- Query language and SQL needs. If analysts and tools need SQL, prefer distributed SQL or a NoSQL system with a SQL-like layer (Couchbase SQL++, Bigtable GoogleSQL for reads, HBase through Apache Phoenix). Proprietary languages such as AQL or RQL mean skills and queries do not transfer.
- Partitioning and hot spots. Ask how the key is chosen and whether it can change later. A poor shard or partition key concentrates traffic on a few nodes and is hard to fix; MongoDB, Cassandra, DynamoDB, HBase and Bigtable all depend on key design for performance.
- Multi-region and active-active. Check whether writes can be accepted in more than one region and how conflicts are handled. Options include Cassandra and ScyllaDB per-data-centre replication, DynamoDB global tables (with a strongly consistent mode), Couchbase XDCR (Enterprise Edition), and row-level regional placement in CockroachDB.
- Licence and lifecycle. Several licences are not OSI open source: MongoDB (SSPL), Couchbase (BSL 1.1), ScyllaDB (source-available since 2025.1, free up to 10 TB and 50 vCPUs for non-customers), ArangoDB (BSL 1.1 since 3.12, with Community binaries limited to non-commercial use under 100 GB) and CockroachDB (proprietary since v24.3, when Core ended). Apache 2.0 options include Cassandra, HBase, CouchDB, FoundationDB, Ignite, YugabyteDB and TiDB. OrientDB has been community-maintained since SAP ended its maintenance in 2023.
- Managed service and cloud lock-in. DynamoDB runs only on AWS, Bigtable only on Google Cloud and Cosmos DB only on Azure. MongoDB Atlas, Couchbase Capella, CockroachDB Cloud, YugabyteDB Aeon, TiDB Cloud and Neo4j AuraDB run on several clouds. Some open source projects (Cassandra, CouchDB, FoundationDB, Ignite) have no managed service from the project, only from third parties.
- Operational burden. Self-managed distributed databases need specialist skills. Cassandra needs repair, compaction and capacity planning; HBase needs HDFS and ZooKeeper; a self-managed TiDB cluster runs TiDB, TiKV, PD and TiFlash components; Vitess-style external sharding is not needed with distributed SQL, but node, zone and region placement still need planning. Managed services remove most of this work.
- Compatibility with existing code. APIs can shorten a migration: ScyllaDB runs CQL applications and offers a DynamoDB-compatible API, YugabyteDB offers PostgreSQL-compatible YSQL and Cassandra-style YCQL, TiDB is MySQL 8.0-compatible, Bigtable has an HBase-compatible client, and Cosmos DB offers MongoDB and Cassandra APIs. Check the unsupported-features list before assuming a drop-in replacement.