The non-relational landscape spans six major categories on this page — in-memory caches, document stores, wide-column tables, distributed and embedded key-value stores, time-series databases, and search engines. Each models data in a way that outperforms an RDBMS for a specific access pattern. Pick the engine that matches the shape of your data and the queries you actually run, not the one with the most familiar SQL dialect. Graph databases have moved to their own section — see Graph Databases.
The most-deployed NoSQL system. In-memory data-structure server — strings, hashes, sorted sets, streams, vectors. Cache, session store, queue, leaderboard, rate limiter in one tool.
The original distributed in-memory cache. Multi-threaded, byte-strings only, no persistence — deliberately simple. Pairs naturally with the Redis comparison.
Document-based NoSQL using BSON with flexible schema. Wins on nested data, schemaless ingest, and fast prototyping where rigid relational tables slow you down.
The original document DB. Multi-master replication, MVCC, HTTP API — the foundation for offline-first mobile and PWA applications via PouchDB / Couchbase Lite.
Distributed document DB merging Membase’s caching with CouchDB’s document model. SQL-style queries via N1QL, built-in cache, full-text search, and analytics in one cluster.
The canonical Dynamo-style wide-column DB. Masterless, multi-region, write-optimized — the storage layer behind Netflix, Apple, Discord, and Instagram.
Cassandra-compatible rewrite in C++ on Seastar. Shard-per-core architecture delivers 5–10× throughput at lower p99 — same data model, far fewer nodes.
Open-source clone of Google Bigtable on HDFS. Strongly consistent, master-coordinated — the wide-column choice when Hadoop is already in production.
Embedded LSM-tree library from Google — fast writes, ordered range scans, and the storage engine behind Chrome IndexedDB and Bitcoin Core.
Meta’s production-grade LevelDB fork — column families, transactions, bloom filters, multi-threaded compaction. Powers MyRocks, CockroachDB, TiKV, Kafka Streams.
Memory-mapped B+tree KV from OpenLDAP. Sub-microsecond reads via mmap, single-writer MVCC, ~10K lines of C. Used by OpenLDAP, Bitcoin Core, monero.
Pure-Go LSM KV with WiscKey value separation. Concurrent writers, ACID transactions — the storage engine inside Dgraph and many Go-native services.
Pure-Go B+tree KV (the etcd team’s fork of BoltDB). Embedded in etcd, Consul, InfluxDB metadata, OPA, NATS Jetstream — the go-to control-plane KV in Go.
Neo4j, Amazon Neptune, JanusGraph, Dgraph — nodes and edges as first-class citizens, with native traversal that beats recursive SQL on connected data.
AWS managed key-value/document database — single-digit-millisecond reads at any scale, with on-demand and provisioned capacity modes.
Specialized similarity-search databases for embeddings — the modern NoSQL companion for AI workloads. HNSW, IVF, and PQ indexing.
Snowflake’s VARIANT type lets a SQL warehouse query JSON/Avro/Parquet natively — the relational counter-move to NoSQL.
About this section. Reach for a document store like MongoDB when records have variable or deeply nested fields and the schema needs to evolve without migrations. Use a distributed key-value engine like FoundationDB when you need low-latency primitives and strict transactional guarantees. Choose Cassandra / ScyllaDB for write-heavy multi-region workloads and Redis for in-memory speed with rich data structures. Use a purpose-built TSDB or search engine when the access pattern (timestamped windows, full-text relevance) doesn’t fit a row-store at all. For relationship-heavy workloads where multi-hop traversals dominate, see Graph Databases.
The three databases occupy fundamentally different tiers: MongoDB is a server-based document database with rich query semantics, while LevelDB and RocksDB are embedded byte-string key-value libraries. Pick based on whether you need a queryable database (MongoDB), an embedded LSM library (LevelDB for simplicity, RocksDB for production scale), or a storage engine to build a distributed system on top of (RocksDB).
| MongoDB | LevelDB | RocksDB | |
|---|---|---|---|
| Architecture | |||
| Deployment | Server (mongod), networked | Embedded library, in-process | Embedded library, in-process |
| Multi-process access | Yes (clients connect over TCP) | No (one writer; directory lock) | No (one writer; directory lock) |
| Storage engine | WiredTiger (B-tree + LSM hybrid) | LSM tree | LSM tree (heavily optimized) |
| Replication | Replica sets, automatic failover | None (build it yourself) | None (used as backend by replicated DBs) |
| Sharding | Built-in (range / hash / zone) | None | None directly; foundation for sharded DBs |
| Data Model | |||
| Records | BSON documents (nested, typed) | (bytes, bytes) | (bytes, bytes) |
| Schema | Flexible, optional validators | None | None |
| Secondary indexes | B-tree, hashed, geo, text, vector | None (compose via key prefixes) | None (compose via key prefixes) |
| Query language | MQL + aggregation pipeline | Get / Put / Iter only | Get / Put / Iter only |
| Joins / aggregations | Yes ($lookup, $group, etc.) | None | None |
| Concurrency & Durability | |||
| Transactions | Multi-document ACID, distributed | Atomic batches only | Optimistic + pessimistic, snapshot isolation |
| Compaction threads | WiredTiger eviction (multi-thread) | 1 | N (configurable, often 8–16) |
| Bloom filters | Internal (WiredTiger) | Manual / off by default | First-class, per-CF |
| Compression | Snappy, ZSTD, ZLIB (per collection) | Snappy | Snappy, LZ4, ZSTD, ZLIB, BZIP2 |
| Backup | mongodump, replica-based, FS snapshot | None built-in | Checkpoint (hard-link) + incremental BackupEngine |
| Operational Footprint | |||
| Code size | ~3M LOC (MongoDB + WiredTiger) | ~25k LOC | ~400k LOC |
| Tuning surface | Moderate | Small | Vast |
| License | SSPL | BSD-3-Clause | Apache 2.0 / GPLv2 |
| Used by | SaaS apps, CMS, IoT, content stores | Chrome IndexedDB, Bitcoin Core | CockroachDB, TiKV, MyRocks, Kafka Streams, Flink |
Numbers below are rough order-of-magnitude estimates for a modern commodity server (16-core CPU, NVMe SSD, 64 GiB RAM), 256-byte values, working set fitting in RAM, durable writes (fsync per group commit). Actual numbers vary 5–10× with key/value size, hardware, and tuning — treat these as a starting frame, not a benchmark.
| Workload | MongoDB | LevelDB | RocksDB |
|---|---|---|---|
| Single Client (1 connection / thread) | |||
| Point read latency (p50) | ~0.5–1 ms (local), 1–3 ms (LAN) | ~5–20 µs (cache hit) | ~3–10 µs (cache hit) |
| Point write latency (p50) | ~1–3 ms (w:1) | ~30–100 µs (async) | ~20–80 µs (async) |
| Sync write (fsync) latency | ~3–10 ms (j:true) | ~1–5 ms | ~1–5 ms |
| Point reads / sec | ~10–30 K | ~200–500 K | ~500 K–1 M |
| Async writes / sec | ~5–15 K | ~50–100 K | ~100–300 K |
| Concurrent Clients (16–128 threads) | |||
| Aggregate point reads / sec | ~50–150 K (scales w/ replicas) | ~500 K–1 M (read-mostly) | ~1–3 M |
| Aggregate writes / sec | ~30–80 K (scales w/ shards) | ~100–200 K (single-thread compaction is the ceiling) | ~500 K–1 M+ (multi-thread compaction) |
| Range scan throughput | ~100–500 K docs/sec (indexed) | ~1–3 M kv/sec | ~2–5 M kv/sec |
| Concurrency model | Connection pool, doc-level locks | Single writer; readers don’t block | Single writer; multi-thread compaction; transaction managers |
| Scale Ceiling (single host) | |||
| Practical dataset size | ~TB per node, PB sharded | ~10s of GB before compaction pain | ~10s of TB |
| Bottleneck under heavy writes | WiredTiger checkpointing, network | Single-thread compaction | Disk bandwidth, then CPU |
| Bottleneck under heavy reads | Network round-trip, query plan | L0 file count without bloom filters | Block cache hit rate |
How to read these numbers. The order-of-magnitude gap between MongoDB and the embedded engines is mostly the network round-trip and query-planning overhead — MongoDB does much more per call. The gap between LevelDB and RocksDB widens dramatically under concurrent writes because LevelDB compacts on a single thread while RocksDB compacts on many. For a workload where MongoDB’s schema, indexes, and aggregations don’t earn their cost, dropping to RocksDB can be a 10–50× throughput win — at the price of writing your own indexes, query layer, and replication.
When the comparison flips. MongoDB’s per-operation overhead is dwarfed when the query itself is non-trivial. A $lookup across two indexed collections in MongoDB can be faster end-to-end than the equivalent application-side join on top of RocksDB, because Mongo runs it close to the data. Always benchmark the actual workload, not synthetic point-read microbenchmarks.