WHAT'S NEW IN 3.x
Headline gains from SurrealDB 2.x to 3.x
↑ 31%
Faster CRUD
Mean across creates, reads, updates, deletes
↑ 58%
Faster batches
Mean across batched operations
↑ 11894%
Full-table scan performance
Mean across non-indexed read scans
↑ 136%
Indexed query performance
Mean across indexed read scans
↑ 27%
Faster CRUD tail latency
Mean p99 across creates, reads, updates, deletes
↑ 32%
Faster batch tail latency
Mean p99 across batched operations
↑ 99%
Faster full-table scan tail latency
Mean p99 across non-indexed read scans
↑ 59%
Faster indexed query tail latency
Mean p99 across indexed read scans
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
22%
slower
Read throughput
vs Redis, point reads by record id
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.8k1× |
| Read | Read-only | 367.9k1× | 348.6k1.1× | 288.1k1.3× |
| Update | Write-only | 89.0k3.4× | 85.2k3.5× | 300.6k1× |
| Delete | Write-only | 100.6k2.8× | 100.0k2.8× | 279.3k1× |
| batch create 100 | Write-only | 2.4k1× | 2.1k1.1× | 2.0k1.2× |
| batch read 100 | Read-only | 16.3k1× | 11.8k1.4× | 3.4k4.8× |
| batch update 100 | Write-only | 2.6k1.0× | 2.1k1.3× | 2.7k1× |
| batch delete 100 | Write-only | 6.7k1× | 5.8k1.1× | 4.3k1.6× |
| batch create 1000 | Write-only | 2731× | 2221.2× | 992.8× |
| batch read 1000 | Read-only | 1.5k1× | 8171.9× | 5103.0× |
| batch update 1000 | Write-only | 2741× | 2261.2× | 1761.6× |
| batch delete 1000 | Write-only | 1.3k1× | 7421.8× | 3204.2× |
| select(id) limit(100) | Read-only | 2.1k18× | 1.1k35× | 37.8k1× |
| select(*) limit(100) | Read-only | 1.3k10× | 87115× | 13.5k1× |
| select(id) start(5000) limit(100) | Read-only | 93321× | 53436× | 19.3k1× |
| select(*) start(5000) limit(100) | Read-only | 74015× | 44025× | 10.8k1× |
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
15,000,000 for the key-value category and 1,000,000 for the embedded category, where SQLite is otherwise prohibitively slow.
128 clients, 48 concurrent queries each
Mixed read/write scans at 15% and 50% write ratios
Run separately, so each ratio is measured on its own.
Every row blends the data types
Strings, integers, floats, enums, UUIDs, datetimes, booleans, a nested geography object, and arrays of tag enums.
Batch operations at 100 and 1,000 rows per batch
Same harness for every engine
The same dataset shape and the same logical operations
Run against every engine.
Queries 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 with and without a matching index
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 pure-read performance.
Full-text BM25 queries on every engine that supports them
Single term, multi-AND and multi-OR, in the engine's idiomatic fulltext syntax.
System isolation
Every benchmark runs on bare metal
No virtualisation, no hypervisor overhead.
Each benchmark waits for a quiet machine
It starts once the 1-minute load average drops below 0.5.
Background services stopped, swap disabled, Transparent Huge Pages off
unattended-upgrades is the service that goes.
Disk caches dropped and memory compacted before and after every run
No database inherits a warmed cache from the previous one.
Process limits raised
65,536 file descriptors, unlimited processes, unlimited memory lock.
Priority and affinity pinned
Process priority with nice / ionice; CPU affinity 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 compiled for release
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.
Every engine on its standard production-durable settings
SQLite, Postgres, MySQL, MongoDB, ArangoDB, Neo4j, Redis, KeyDB and SurrealDB all run this way, 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
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 one exception is the in-memory key-value variant
There every engine in the comparison (Redis, KeyDB, Dragonfly, SurrealDB) runs purely in memory with no persistence.
What we capture
The full latency distribution per operation
min, p01, p25, p50, p75, p95, p99, max and IQR - so tail-latency regressions cannot 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 preserved and shipped with the page
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.
ON THE ROADMAP
More comparisons, on their way. The workloads and engines this page adds next.
Distributed database comparisons
Clustered configurations of CockroachDB, TiDB, MongoDB and Aerospike running the same workload across multiple nodes.
Vector search
HNSW vector similarity across the multi-model engines, with throughput and recall at varying index parameters.
Full-text search
BM25 full-text comparisons against MongoDB, Postgres, MySQL, Neo4j and ArangoDB: single-term, AND and OR queries.
Graph queries
Multi-hop graph traversal workloads against Neo4j and ArangoDB on the same dataset.
MariaDB
The relational comparison extended to MariaDB, on the same workload Postgres and MySQL run today.
JOIN-shaped workloads
Multi-table joins against Postgres, MySQL and MariaDB, beside the point reads the relational category reports now.
Related resources
Introducing SurrealDB 3.1
The operational maturity release - production stability, DiskANN, and observability.
Our benchmarking journey
How we approach benchmarking a multi-model database - methodology and learnings.
crud-bench on GitHub
Our open-source benchmarking tool - run your own benchmarks and contribute.
THE PLATFORM
Everything an application and its agents know. Five surfaces, one engine.
Database
Document, graph, vector, time-series and relational in one engine.
Agent Memory
What an agent learns, with its source and its time, in the same engine.
Cloud
Managed clusters in the regions you choose, scaled on demand.
Studio
Query, explore and design the schema from the browser.
MCP
Every model that speaks MCP reaches the database and the memory directly.
IN PRODUCTION
Trusted at scale. Samsung, Nvidia, Verizon, Tencent and Walmart run on SurrealDB.
14,000+
Developers building on SurrealDB Cloud
4M+
Developers building on SurrealDB worldwide
FROM THE TEAMS
SurrealDB gives us a foundation where we can unify semantic search, knowledge graphs, and AI-driven decision making without stitching together multiple systems. Collapsing responsibility into SurrealDB has become our default engineering posture.
VP of Engineering, Later
GET STARTED