--- title: "SurrealDB Benchmarks | Performance | SurrealDB" description: "Open-source benchmarks of SurrealDB 3.x against the leading key-value, embedded, relational, document, and graph databases - same hardware, same harness." url: https://surrealdb.com/surrealdb/benchmarks --- BENCHMARKS # Multi-model performance across core workloads SurrealDB compared against the leading key-value, embedded, relational, document, and graph databases - using the same open-source benchmarking harness on the same hardware. [Try SurrealDB 3.x](https://studio.surrealdb.com/current/instances/deploy) [View benchmarking tool](https://github.com/surrealdb/crud-bench) 1. ![Babcock](https://surrealdb.com/assets/static/babcock.lo4rnVg1.svg) 2. ![ING](https://surrealdb.com/assets/static/ing.X3I6S3_V.svg) 3. ![British Airways](https://surrealdb.com/assets/static/british-airways.KEsZiwV-.svg) 4. ![Nvidia](https://surrealdb.com/assets/static/nvidia.DaIEuMil.svg) 5. ![Apple](https://surrealdb.com/assets/static/apple.D5pq4flY.svg) 6. ![SpaceX](https://surrealdb.com/assets/static/spacex.CQJEk-IL.svg) 7. ![Samsung](https://surrealdb.com/assets/static/samsung.CH-vQgnb.svg) 8. ![adidas](https://surrealdb.com/assets/static/adidas.DdTC5qhk.svg) 9. ![Tencent](https://surrealdb.com/assets/static/tencent.paQmLxyy.svg) 10. ![Alibaba](https://surrealdb.com/assets/static/alibaba.B16idgfM.svg) 11. ![PolyAI](https://surrealdb.com/assets/static/poly-ai.c3w_fAg6.svg) 12. ![Later](https://surrealdb.com/assets/static/later.Ds736jFO.svg) 13. ![Verizon](https://surrealdb.com/assets/static/verizon.BI7CajdX.svg) 14. ![Liberty Mutual](https://surrealdb.com/assets/static/liberty-mutual.B7qOU1pd.svg) 15. ![Walmart](https://surrealdb.com/assets/static/walmart.BjDg_Sr8.svg) 16. ![Carrier](https://surrealdb.com/assets/static/carrier.D21gC6NX.svg) 17. ![Saks Fifth Avenue](https://surrealdb.com/assets/static/saks-fifth-avenue.COIDpLSb.svg) 18. ![San Francisco Compute Company](https://surrealdb.com/assets/static/sfcc.B7jlImq4.svg) 19. ![Shield AI](https://surrealdb.com/assets/static/shield-ai.pINZ0KJr.svg) 20. ![Wix](https://surrealdb.com/assets/static/wix.DvHhmoBi.svg) 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 Mixed (50% write) SurrealDB 1.x 78k ops/s baseline SurrealDB 2.x 107k ops/s 1.4× SurrealDB 3.x 141k ops/s 1.8× Batch throughput Mean across batched CRUD operations Mixed (50% write) SurrealDB 1.x 690 ops/s baseline SurrealDB 2.x 884 ops/s 1.3× SurrealDB 3.x 1k ops/s 2.0× Full table scan throughput Mean across non-indexed read scans Read-only SurrealDB 1.x 0.06 ops/s baseline SurrealDB 2.x 0.09 ops/s 1.4× SurrealDB 3.x 11 ops/s 164× Indexed lookup throughput Mean across indexed read scans Read-only SurrealDB 1.x 32 ops/s baseline SurrealDB 2.x 44 ops/s 1.4× SurrealDB 3.x 104 ops/s 3.2× 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. Key-value Embedded Relational Document Graph ### SurrealDB vs Redis, KeyDB Redis-class throughput with full database semantics. Engine: SurrealDB server (in-memory, with AOL persistence) In-memory with AOL persistence In-memory with no 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 Throughput Mean latency p99 latency #### 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 Write-only Throughput (higher is better) Redis 85.8k ops/s KeyDB 79.5k ops/s SurrealDB 300.8k ops/s Read Read-only Throughput (higher is better) Redis 367.9k ops/s KeyDB 348.6k ops/s SurrealDB 288.1k ops/s Update Write-only Throughput (higher is better) Redis 89.0k ops/s KeyDB 85.2k ops/s SurrealDB 300.6k ops/s Delete Write-only 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 Write-only 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 Read-only 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 Write-only 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 Write-only 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 Write-only Throughput (higher is better) Redis 273 ops/s KeyDB 222 ops/s SurrealDB 99 ops/s Batch read (1000) 1000 ops per batch Read-only Throughput (higher is better) Redis 1.5k ops/s KeyDB 817 ops/s SurrealDB 510 ops/s Batch update (1000) 1000 ops per batch Write-only Throughput (higher is better) Redis 274 ops/s KeyDB 226 ops/s SurrealDB 176 ops/s Batch delete (1000) 1000 ops per batch Write-only 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. Heatmap Chart Redis KeyDB SurrealDB Colour shows speed relative to the fastest engine per row. A factor (e.g. 12×) marks how much slower a cell is than that best result. Slower Faster | Operation | Workload | Redis | KeyDB | SurrealDB | | --- | --- | --- | --- | --- | | Create | Write-only | 85.8k 3.5× | 79.5k 3.8× | 300.8k 1× | | Read | Read-only | 367.9k 1× | 348.6k 1.1× | 288.1k 1.3× | | Update | Write-only | 89.0k 3.4× | 85.2k 3.5× | 300.6k 1× | | Delete | Write-only | 100.6k 2.8× | 100.0k 2.8× | 279.3k 1× | | batch create 100 | Write-only | 2.4k 1× | 2.1k 1.1× | 2.0k 1.2× | | batch read 100 | Read-only | 16.3k 1× | 11.8k 1.4× | 3.4k 4.8× | | batch update 100 | Write-only | 2.6k 1.0× | 2.1k 1.3× | 2.7k 1× | | batch delete 100 | Write-only | 6.7k 1× | 5.8k 1.1× | 4.3k 1.6× | | batch create 1000 | Write-only | 273 1× | 222 1.2× | 99 2.8× | | batch read 1000 | Read-only | 1.5k 1× | 817 1.9× | 510 3.0× | | batch update 1000 | Write-only | 274 1× | 226 1.2× | 176 1.6× | | batch delete 1000 | Write-only | 1.3k 1× | 742 1.8× | 320 4.2× | | select(id) limit(100) | Read-only | 2.1k 18× | 1.1k 35× | 37.8k 1× | | select(*) limit(100) | Read-only | 1.3k 10× | 871 15× | 13.5k 1× | | select(id) start(5000) limit(100) | Read-only | 933 21× | 534 36× | 19.3k 1× | | select(*) start(5000) limit(100) | Read-only | 740 15× | 440 25× | 10.8k 1× | 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 ` on their own hardware to reproduce a comparison. [View crud-bench on GitHub](https://github.com/surrealdb/crud-bench) [Methodology blog post](https://surrealdb.com/blog/beginning-our-benchmarking-journey) 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. RESOURCES ## Related resources Dive deeper into how we built crud-bench and what's coming next. ### [Introducing SurrealDB 3.1](https://surrealdb.com/3.1) The operational maturity release - production stability, DiskANN, and observability. Learn more ### [Our benchmarking journey](https://surrealdb.com/blog/beginning-our-benchmarking-journey) How we approach benchmarking a multi-model database - methodology and learnings. Learn more ### [crud-bench on GitHub](https://github.com/surrealdb/crud-bench) Our open-source benchmarking tool - run your own benchmarks and contribute. Learn more GET STARTED ## Ready to experience the performance? Try SurrealDB 3.x today. Join the community on Discord to chat directly with the team. ![Samsung](https://surrealdb.com/assets/static/4c58b81e7b3c9466.C_Hv0eml.svg)![NVIDIA](https://surrealdb.com/assets/static/nvidia.DaIEuMil.svg)![Apple](https://surrealdb.com/assets/static/f7dc2519e0d212bc.Cn8MYAK7.svg)![Verizon](https://surrealdb.com/assets/static/18b99996c689000f.B5PQ-nI9.svg)![Tencent](https://surrealdb.com/assets/static/401d8346058682c8.DqM87mst.svg) SOC 2 Type 2 GDPR Cyber Essentials Plus ISO 27001 [Try SurrealDB 3.x](https://studio.surrealdb.com/current/instances/deploy) [Join our Discord](https://discord.gg/surrealdb) ```json {"@context":"https://schema.org","@type":"Organization","name":"SurrealDB","url":"https://surrealdb.com","logo":"https://surrealdb.com/assets/static/logo.BG7_TG2b.svg","description":"SurrealDB is the unified data layer for AI. A multi-model database for documents, graphs, vectors, and time-series.","foundingDate":"2022","hasCertification":[{"@type":"Certification","name":"SOC 2 Type 2"},{"@type":"Certification","name":"GDPR"},{"@type":"Certification","name":"Cyber Essentials Plus"},{"@type":"Certification","name":"ISO 27001"}],"owns":[{"@type":"SoftwareApplication","name":"SurrealDB","url":"https://surrealdb.com/surrealdb"},{"@type":"SoftwareApplication","name":"Agent Memory","url":"https://surrealdb.com/agent-memory"}],"knowsAbout":["multi-model databases","document databases","graph databases","vector search","time-series databases","SurrealQL","Agent Memory","real-time databases","embedded databases","context layer","graph ontology","distributed database","knowledge graphs","distributed transaction protocols","highly-scalable databases"],"sameAs":["https://www.wikidata.org/wiki/Q124316308","https://github.com/surrealdb/surrealdb","https://twitter.com/surrealdb","https://www.youtube.com/@surrealdb","https://www.linkedin.com/company/surrealdb","https://discord.gg/surrealdb","https://www.reddit.com/r/surrealdb","https://www.instagram.com/surrealdb","https://medium.com/surrealdb","https://dev.to/surrealdb"]} ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://surrealdb.com"},{"@type":"ListItem","position":2,"name":"SurrealDB","item":"https://surrealdb.com/surrealdb"},{"@type":"ListItem","position":3,"name":"Benchmarks","item":"https://surrealdb.com/surrealdb/benchmarks"}]} ```