WHAT'S NEW IN 3.x
Headline gains from SurrealDB 2.x to 3.x
The most significant throughput and latency improvements unlocked by the new execution engine.
↑ 31%
Faster CRUD
Mean across creates, reads, updates, deletes - 2.x to 3.x
↑ 58%
Faster batches
Mean across batched operations - 2.x to 3.x
↑ 11894%
Full-table scan performance
Mean across non-indexed read scans - 2.x to 3.x
↑ 136%
Indexed query performance
Mean across indexed read scans - 2.x to 3.x
↑ 27%
Faster CRUD tail latency
Mean p99 across creates, reads, updates, deletes - 2.x to 3.x
↑ 32%
Faster batch tail latency
Mean p99 across batched operations - 2.x to 3.x
↑ 99%
Faster full-table scan tail latency
Mean p99 across non-indexed read scans - 2.x to 3.x
↑ 59%
Faster indexed query tail latency
Mean p99 across indexed read scans - 2.x to 3.x
VERSION TO VERSION
SurrealDB across versions
Throughput improvements from SurrealDB 1.x through 3.x, summarised across the major workload classes. Higher is better.
CRUD throughput
Mean across creates, reads, updates, deletes
Batch throughput
Mean across batched CRUD operations
Full table scan throughput
Mean across non-indexed read scans
Indexed lookup throughput
Mean across indexed read scans
CROSS-DATABASE
Compare across database categories
SurrealDB benchmarked against the most-deployed database in each category - using the same workload, the same harness, the same hardware.
SurrealDB vs Redis, KeyDB
Redis-class throughput with full database semantics.
Engine: SurrealDB server (in-memory, with AOL persistence)
1.8× faster
CRUD throughput
vs Redis, mean across creates, reads, updates, deletes
62% faster
Mean latency
vs Redis, mean across CRUD operations
24% faster
p99 latency
vs Redis, mean across CRUD operations
CRUD operations
Single-record creates, reads, updates, and deletes against 15,000,000 records keyed by randomly-generated string IDs - never sequential, so engines cannot benefit from key locality. For SurrealDB, every operation runs inside its own snapshot-isolated, atomic transaction. The 128 clients each maintain 48 concurrent connections, and every operation is a single round-trip against a freshly-populated database.
Create
Throughput (higher is better)
Redis
85.8k ops/s
KeyDB
79.5k ops/s
SurrealDB
300.8k ops/s
Read
Throughput (higher is better)
Redis
367.9k ops/s
KeyDB
348.6k ops/s
SurrealDB
288.1k ops/s
Update
Throughput (higher is better)
Redis
89.0k ops/s
KeyDB
85.2k ops/s
SurrealDB
300.6k ops/s
Delete
Throughput (higher is better)
Redis
100.6k ops/s
KeyDB
100.0k ops/s
SurrealDB
279.3k ops/s
Batch operations
The same create / read / update / delete operations bundled into single requests of 100 and 1,000 rows. 1,000 batches are timed per operation per batch size, measuring how efficiently each engine commits a bulk of work in a single network round-trip and storage transaction.
Batch create (100)
100 ops per batch
Throughput (higher is better)
Redis
2.4k ops/s
KeyDB
2.1k ops/s
SurrealDB
2.0k ops/s
Batch read (100)
100 ops per batch
Throughput (higher is better)
Redis
16.3k ops/s
KeyDB
11.8k ops/s
SurrealDB
3.4k ops/s
Batch update (100)
100 ops per batch
Throughput (higher is better)
Redis
2.6k ops/s
KeyDB
2.1k ops/s
SurrealDB
2.7k ops/s
Batch delete (100)
100 ops per batch
Throughput (higher is better)
Redis
6.7k ops/s
KeyDB
5.8k ops/s
SurrealDB
4.3k ops/s
Batch create (1000)
1000 ops per batch
Throughput (higher is better)
Redis
273 ops/s
KeyDB
222 ops/s
SurrealDB
99 ops/s
Batch read (1000)
1000 ops per batch
Throughput (higher is better)
Redis
1.5k ops/s
KeyDB
817 ops/s
SurrealDB
510 ops/s
Batch update (1000)
1000 ops per batch
Throughput (higher is better)
Redis
274 ops/s
KeyDB
226 ops/s
SurrealDB
176 ops/s
Batch delete (1000)
1000 ops per batch
Throughput (higher is better)
Redis
1.3k ops/s
KeyDB
742 ops/s
SurrealDB
320 ops/s
Simple scans
Count and pagination operations without filters - the baseline scan performance.
First 100 rows
Throughput (higher is better)
Redis
1.3k ops/s
KeyDB
871 ops/s
SurrealDB
13.5k ops/s
Offset pagination
Throughput (higher is better)
Redis
740 ops/s
KeyDB
440 ops/s
SurrealDB
10.8k ops/s
Detailed comparison
Explore every operation interactively. Pick the databases to compare, then read the heatmap to spot where each engine wins or falls behind, chart a single operation head-to-head, or read the raw table. Switch the metric above to view throughput, mean latency, or p99.
| Operation | Workload | Redis | KeyDB | SurrealDB |
|---|---|---|---|---|
| Create | Write-only | 85.8k3.5× | 79.5k3.8× | 300.8k |
| Read | Read-only | 367.9k | 348.6k1.1× | 288.1k1.3× |
| Update | Write-only | 89.0k3.4× | 85.2k3.5× | 300.6k |
| Delete | Write-only | 100.6k2.8× | 100.0k2.8× | 279.3k |
| batch create 100 | Write-only | 2.4k | 2.1k1.1× | 2.0k1.2× |
| batch read 100 | Read-only | 16.3k | 11.8k1.4× | 3.4k4.8× |
| batch update 100 | Write-only | 2.6k | 2.1k1.3× | 2.7k |
| batch delete 100 | Write-only | 6.7k | 5.8k1.1× | 4.3k1.6× |
| batch create 1000 | Write-only | 273 | 2221.2× | 992.8× |
| batch read 1000 | Read-only | 1.5k | 8171.9× | 5103.0× |
| batch update 1000 | Write-only | 274 | 2261.2× | 1761.6× |
| batch delete 1000 | Write-only | 1.3k | 7421.8× | 3204.2× |
| select(id) limit(100) | Read-only | 2.1k18× | 1.1k35× | 37.8k |
| select(*) limit(100) | Read-only | 1.3k10× | 87115× | 13.5k |
| select(id) start(5000) limit(100) | Read-only | 93321× | 53436× | 19.3k |
| select(*) start(5000) limit(100) | Read-only | 74015× | 44025× | 10.8k |
METHODOLOGY
How these benchmarks are run
All results are produced by the open-source crud-bench harness running against a fresh instance of each database on the same hardware.
Workload
• 5,000,000 records per test, except 15,000,000 for the key-value category and 1,000,000 for the embedded category (SQLite is otherwise prohibitively slow).
• 128 clients, 48 concurrent queries each.
• Mixed read/write scans run at 15% and 50% write ratios (separate runs).
• Each row blends strings, integers, floats, enums, UUIDs, datetimes, booleans, a nested geography object, and arrays of tag enums.
• Batch operations run at both 100 and 1,000 rows per batch.
Same harness for every engine
• Same dataset shape and the same logical operations are run against every engine.
• Queries are translated to each engine's native dialect - SQL variants, MongoDB filter documents, Cypher fragments, SurrealQL - so no engine is penalised for not speaking another's language.
• Every WHERE-based scan runs both with and without a matching index, so raw scan cost and index acceleration are reported separately.
• Mixed read/write scans interleave UPDATEs at 15% and 50% write ratios, so sustained throughput is measured rather than just pure-read performance.
• Full-text BM25 queries (single term, multi-AND, multi-OR) are run on every engine that supports them, using the engine's idiomatic fulltext syntax.
System isolation
• Every benchmark runs on bare metal - no virtualisation, no hypervisor overhead.
• Each benchmark waits until the 1-minute load average drops below 0.5 before starting.
• Background services are stopped (unattended-upgrades), swap is disabled, and Transparent Huge Pages are turned off.
• Disk caches are dropped and memory compacted before and after every run, so no database inherits a warmed cache from the previous one.
• Process limits are raised: 65,536 file descriptors, unlimited processes, unlimited memory lock.
• Process priority is pinned with nice / ionice; CPU affinity is pinned with taskset.
• Each database runs alone on the machine. Between runs the data directory is wiped and the Docker volume is recreated, so every database starts from an identical, empty state.
• crud-bench is compiled with cargo build --release, so harness overhead is minimised.
Durability & disk sync
• Every persistent benchmark runs in full durability mode: each committed transaction is flushed and fsync'd to disk before it is acknowledged, matching how these engines should be configured in production.
• SQLite, Postgres, MySQL, MongoDB, ArangoDB, Neo4j, Redis, KeyDB, and SurrealDB all run with their standard production-durable settings, so no engine gains an advantage by skipping disk sync. Dragonfly is the exception - it has no on-disk mode in this comparison.
• The common settings used to enforce this: fsync = on and synchronous_commit = on for Postgres; innodb_flush_log_at_trx_commit = 1 and sync_binlog = 1 for MySQL; and journaled write concern { j: true } for MongoDB.
• SurrealDB runs with disk sync enabled. Note that SurrealDB 2.x did not enable sync by default, whereas SurrealDB 3.x enables it by default - so the 3.x numbers reflect the same full-durability guarantee as the other engines.
• The only exception is the in-memory key-value variant, where every engine in the comparison (Redis, KeyDB, Dragonfly, SurrealDB) runs purely in memory with no persistence.
What we capture
• Full latency distribution per operation: min, p01, p25, p50, p75, p95, p99, max, and IQR - so tail-latency regressions can't hide behind a clean mean.
• Resource accounting per benchmark: CPU avg/min/max, memory avg/min/max, disk read/write bytes, and system load.
• All raw JSON output is preserved and ships with the page, so a reader can re-derive every chart from the source numbers.
Hardware
Same single-node machine used across every comparison (last run 28 May 2026).
| Component | Specification |
|---|---|
| CPU | AMD Ryzen Threadripper 9970X (32 cores / 64 threads, x86_64) |
| RAM | 2 × Samsung DDR5 4800MHz 64GB RDIMM (128 GiB total) |
| SSD | Lexar EQ790 4TB NVMe |
| Motherboard | ASUS PRO WS TRX50-SAGE WIFI A |
| CPU Cooler | Arctic Freezer 4U-M |
| Power Supply | CORSAIR RM1000x |
| GPU | PowerColor AMD Radeon RX 7600 Fighter 8GB |
| Case | In-Win IW-R400-01N 4U |
| OS | Ubuntu 24.04 (kernel 6.8.0-111-generic) |
Caveats & reproducibility
All writes are fully durable (see Durability & disk sync above) except in the key-value, in-memory variant, where every database in the comparison runs in-memory as well.
Embedded engines (SQLite, embedded SurrealDB) run in-process; networked engines (Postgres, MongoDB, Neo4j, networked SurrealDB) run in Docker over localhost TCP. Categories should be compared independently.
crud-bench is open source and the full workload spec lives in bench.toml. Any reader can run ./run.sh -d <db> on their own hardware to reproduce a comparison.
WHAT'S NEXT
On the roadmap
More comparisons we're working on adding to this page.
Coming soon
Distributed database comparisons
Clustered configurations of CockroachDB, TiDB, MongoDB, and Aerospike running the same workload across multiple nodes.
Coming soon
Vector search
HNSW vector similarity benchmarks across the multi-model engines, with throughput and recall at varying index parameters.
Coming soon
Full-text search
BM25 full-text comparisons against MongoDB, Postgres, MySQL, Neo4j, and ArangoDB - single-term, AND, and OR queries.
Coming soon
Graph queries
Multi-hop graph traversal workloads against Neo4j and ArangoDB on the same dataset.
