We are replacing RocksDB with SurrealKV 1.0
Author: Tobie Morgan Hitchcock
SurrealKV 1.0 is a new open source persistent storage engine for SurrealDB, written in Rust and released under Apache 2.0 on 13 October 2026. With synchronous durability, it reads 7.95× faster than RocksDB and 73.7× faster than SlateDB, and it will be the only persistent storage engine in SurrealDB 4.
Why replace RocksDB?
RocksDB is a very good engine, and SurrealDB has run on it for years. It is also a large C++ library that SurrealDB does not control. SurrealKV is an engine we can read from end to end, change when SurrealDB needs it to change, and ship as a Rust crate.
SurrealKV is a log-structured merge-tree with snapshot-isolated transactions. It runs embedded in an application and as the storage layer of a SurrealDB server.
How does SurrealKV reach these numbers?
Three design decisions each remove shared work or shared waiting from a hot path.
- A radix-tree memtable. Writes land in a concurrent adaptive radix tree allocated from a fixed arena. RocksDB and Pebble use skiplists.
- A commit ring. Many committers validate their transactions at the same time. One flusher task then orders what has accumulated into a group, appends it to the write-ahead log with at most one fsync, applies it to the memtable and publishes it. A burst of commits costs one log append.
- Cheap reads. A read pins a sequence number and nothing else.
What else does SurrealKV include?
- Versioned trees, opt in. get_at reads a key as of a time, history returns every version of a key, and compaction keeps versions for a retention period that you set.
- Value separation, opt in, for values larger than 1 KiB, so that compaction does not rewrite large values again and again.
- Encryption at rest, transparent, with AES-256-GCM or XChaCha20-Poly1305.
- Differential testing against an in-memory reference model: 500 seeds of 5,000 steps each, 2,500,000 operations, in every CI run. Any divergence fails the run.
What do the benchmarks show?
With synchronous durability, every commit is flushed to disk before it returns. SurrealKV 1.0 delivered these results on 13 October 2026:
| Engine | Point reads (OPS) | Creates (OPS) | Updates (OPS) | Deletes (OPS) | Scans (OPS) |
|---|---:|---:|---:|---:|---:|
| SurrealKV | 6,804,864 | 229,376 | 221,341 | 264,089 | 905,132 |
| RocksDB | 855,851 | 8,568 | 36,263 | 32,043 | 852,661 |
| SlateDB | 92,303 | 8,257 | 8,122 | 8,242 | 17,985 |
Against RocksDB, SurrealKV is 7.95× faster on point reads, 6.10× faster on updates, 8.24× faster on deletes and 1.06× faster on range scans. Against SlateDB, which ran on local disk and not on object storage, it is 73.7× faster on point reads and 27.3× faster on updates.
SurrealKV creates records 26.8× faster than RocksDB. RocksDB's create rate with synchronous durability is far below its own update rate of 36,263 operations a second, and we have not explained why, so this post does not headline it.
The benchmark ran with crud-bench on an AMD Ryzen Threadripper 9970X (32 cores, 64 threads) with 128 GB of RAM and a 4 TB NVMe SSD. It used 500,000 keys, 48 worker threads and 128 clients. The harness runs SurrealKV with value separation on and a larger memtable than the engine's defaults. Each figure is a single run. Fjall, ReDB, LMDB and libmdbx are not in the table, because their runs with synchronous durability were too slow to finish at this dataset size.
Where is RocksDB faster?
Without synchronous durability, RocksDB is faster at writes. SurrealKV is 1.88× slower on creates, 2.22× slower on updates and 2.41× slower on deletes, and 8.26× faster on point reads.
Without synchronous durability, the engines also make different promises about what survives a crash, so those figures measure speed and not safety. Only the synchronous-durability table compares engines that each flush before acknowledging.
How do range scans compare?
Without synchronous durability, SurrealKV scans the first 100 key-value pairs of the dataset 896,366 times a second. LMDB leads that scan at 1,192,772 scans a second, and RocksDB manages 851,848. The table shows scans per second over the same 500,000 keys, with 5,000,000 iterations of each scan.
| Engine | Limit (OPS) | Keys, limit (OPS) | Skip + limit (OPS) | Keys, skip + limit (OPS) | Full count (OPS) |
|---|---:|---:|---:|---:|---:|
| SurrealKV | 896,366 | 2,313,942 | 96,365 | 98,612 | 402 |
| RocksDB | 851,848 | 851,580 | 35,539 | 35,902 | 159 |
| SlateDB | 26,187 | 26,266 | 7,460 | 7,477 | 87 |
| Fjall | 132,698 | 151,861 | 4,335 | 4,383 | 42.4 |
| ReDB | 561,837 | 571,629 | 44,438 | 44,462 | 249 |
| LMDB | 1,192,772 | 1,195,166 | 549,220 | 552,090 | 902 |
| libmdbx | 384,128 | 260,769 | 183,361 | 185,073 | 848 |
- Limit (select(*) limit(100)) returns the first 100 key-value pairs of the range. Keys, limit (select(id) limit(100)) returns only the keys.
- Skip + limit (select(*) start(5000) limit(100)) walks and discards 5,000 entries before returning 100. Keys, skip + limit returns only the keys.
- Full count (count()) visits every key in the range.
Against RocksDB, SurrealKV is 1.05× faster on the first 100 pairs, 2.72× faster on a keys-only scan of the first 100 entries, 2.71× faster on scans that skip 5,000 entries and 2.53× faster on full counts. SurrealKV leads every engine on the keys-only scan, at 2,313,942 scans a second.
LMDB leads SurrealKV on the first 100 key-value pairs (1.33× faster), on scans that skip 5,000 entries (5.70× faster) and on full counts (2.24× faster).
How much memory does SurrealKV use?
SurrealKV has the lowest resting memory of the seven engines measured, at 221 MiB, against 590 MiB for RocksDB. Resting and peak memory are the lowest and highest process memory sampled across the whole benchmark run, without synchronous durability.
| Engine | Resting memory | Peak memory |
|---|---:|---:|
| SurrealKV | 221 MiB | 1.79 GiB |
| RocksDB | 590 MiB | 1.02 GiB |
| SlateDB | 265 MiB | 2.73 GiB |
| Fjall | 627 MiB | 1.71 GiB |
| ReDB | 257 MiB | 2.17 GiB |
| LMDB | 776 MiB | 826 MiB |
| libmdbx | 40.98 GiB | 117.71 GiB |
SurrealKV's peak memory of 1.79 GiB is higher than that of RocksDB (1.02 GiB) and LMDB (826 MiB), because parallel commits buffer active batches. The libmdbx figures are what the harness measured, and we have not investigated them.
Where is the design written down?
The SurrealKV whitepaper, "A Versioned LSM Engine with Radix-Tree Memtables and a Commit Ring", explains how SurrealKV reaches these numbers, what each design decision costs and what the measurements do not cover.
How can you run the benchmark yourself?
Every figure comes from one command on one machine. Run it on your own hardware:
CRUD_BENCH_CONFIG=config/memory.toml ./run.sh -d surrealkv --no-build --optimised --sync -s 500000 -c 128 -t 48
Change the -d flag to run a comparator, and remove --sync to run without synchronous durability. If you find a fairer configuration for a comparator, open an issue or a pull request on the crud-bench repository.
SurrealKV is open source on GitHub. To use it in a Rust project, add the crate:
cargo add surrealkv
Speed or durability? Yes. Stop choosing.
20 reactions
Our commitment to open source: show the code, run the numbers
Author: Tobie Morgan Hitchcock
We commit to three things: show the code, run the numbers, and say what we did not measure. SurrealKV and SurrealMX are open source under Apache 2.0, SurrealDB is source available under the Business Source License 1.1, and every benchmark we publish comes with the command, the hardware and the method behind it.
A database is a trust relationship. It holds your data, it decides what survives a crash, and it decides who can see what. Infrastructure that agents depend on, running unattended at a scale nobody can supervise, has to earn that trust in a way anyone can check. This post sets out how we intend to earn it.
Why does SurrealDB publish its code?
A claim about a database is only worth what you can check. There are three ways to check ours: read the code, run the benchmark, and read the paper that explains the design and its limits. We publish all three.
That is why you can read the SurrealDB source, why the two new storage engines are open source, and why every benchmark we publish comes with the command to run it. When a database tells you it is fast, correct or safe, you should not have to take its word for it.
What does source available mean?
We use two terms and keep them apart.
- Source available means you can read the code and run it yourself, under a licence that restricts some uses.
- Open source means an Apache 2.0 or MIT licence with no such restriction.
SurrealDB is source available. It is released under the Business Source License 1.1, which is free for internal use and converts to Apache 2.0 after four years. SurrealDB Cloud and Enterprise Edition are commercial products. Everything this post calls open source is under Apache 2.0 or MIT.
What is open source today?
| Project | Licence | What it is |
|---|---|---|
| SurrealKV 1.0 | Apache 2.0 | A persistent storage engine: a log-structured merge-tree with snapshot-isolated transactions and optional versioned trees, built on a concurrent adaptive radix tree memtable and a commit ring. It will be the only persistent storage engine in SurrealDB 4. |
| SurrealMX 1.0 | Apache 2.0 | An in-memory storage engine: multi-version concurrency control over a concurrent adaptive radix tree, with lock-free reads and optional persistence. |
| crud-bench | Apache 2.0 | The benchmark harness behind every performance number we publish. |
Our SDKs and tools, and many of the libraries beneath SurrealDB, are also open source under Apache 2.0 or MIT. The full list is at surrealdb.com.
Each storage engine has a whitepaper. It explains how the engine reaches its performance, what we measured, and what we did not. We will also publish accompanying technical or academic papers for a number of our product launches.
What stays open source?
The storage engines, our SDKs and tools, and the libraries listed at surrealdb.com stay open source, under Apache 2.0 or MIT.
How can I run the benchmarks myself?
Every performance number we publish comes from crud-bench, on one machine: an AMD Ryzen Threadripper 9970X (32 cores, 64 threads) with 128 GB of RAM and a 4 TB NVMe SSD. The same harness and the same command run each comparator, so a number and the number it is compared with are measured the same way.
We say what we compared. When an engine runs in memory, we say it runs in memory. When we compare against an engine on disk, we say it is on disk.
SurrealKV runs with synchronous durability, against RocksDB, SlateDB (on disk, not object storage), Fjall, ReDB, LMDB and libmdbx:
CRUD_BENCH_CONFIG=config/memory.toml ./run.sh -d surrealkv --no-build --optimised --sync -s 500000 -c 128 -t 48
SurrealMX runs against LMDB and RocksDB, both in memory:
CRUD_BENCH_CONFIG=config/memory.toml ./run.sh -d surrealmx --no-build --optimised -s 15000000 -c 128 -t 48
Change the -d flag to run a comparator.
Run it on your own hardware. If you find a fairer configuration for a comparator, or an engine we should have included, open an issue or a pull request on crud-bench. A benchmark that only we can run is not a benchmark.
Whose work does SurrealDB build on?
None of this started with us. SurrealKV belongs to the line of log-structured merge-trees that runs from Bigtable through LevelDB and RocksDB, and we compare it against them. SurrealMX builds on the adaptive radix tree and on the multi-version designs of Hekaton and Silo.
Those ideas were published by people who let strangers read their work, and several of the engines we compare against are open source. We owe that openness a return. The whitepapers cite what we learned from.
What will you hold us to?
Three things.
- Show the code. The engines and tools above stay open source.
- Run the numbers. Every benchmark ships with its command, its hardware and its method.
- Say what we did not measure. Each whitepaper lists what its measurements leave out, and we will keep doing that.
Hold us to them. If we fall short, tell us.
Looking forward
We want infrastructure that anyone can inspect and anyone can challenge. Agents change what a database has to do. They work in volume, they share state, they carry context from one session to the next, and they need to show their work. The launches from 12 to 16 October 2026 cover that stack from the bottom up: from the storage engine, to the database layer, to the collaborative primitives that enable agents to work at pace, and at scale. All of it sits on one database, SurrealDB, and every benchmark comes with the command to run it.
That is the foundation. We will set out our full view of infrastructure for the agentic future in a separate post.
11 reactions
Mentions
We are replacing RocksDB with SurrealKV 1.0 Author: Tobie Morgan Hitchcock SurrealKV 1.0 is a new open source persistent storage engine for SurrealDB, written in Rust and released under Apache 2.0 on 13 October 2026. With synchronous durability, it reads 7.95× faster than RocksDB and 73.7× faster than SlateDB, and it will be the only persistent storage engine in SurrealDB 4. Why replace RocksDB? RocksDB is a very good engine, and SurrealDB has run on it for years. It is also a large C++ library that SurrealDB does not control. SurrealKV is an engine we can read from end to end, change when SurrealDB needs it to change, and ship as a Rust crate. SurrealKV is a log-structured merge-tree with snapshot-isolated transactions. It runs embedded in an application and as the storage layer of a SurrealDB server. How does SurrealKV reach these numbers? Three design decisions each remove shared work or shared waiting from a hot path. - A radix-tree memtable. Writes land in a concurrent adaptive radix tree allocated from a fixed arena. RocksDB and Pebble use skiplists. - A commit ring. Many committers validate their transactions at the same time. One flusher task then orders what has accumulated into a group, appends it to the write-ahead log with at most one fsync, applies it to the memtable and publishes it. A burst of commits costs one log append. - Cheap reads. A read pins a sequence number and nothing else. What else does SurrealKV include? - Versioned trees, opt in. get_at reads a key as of a time, history returns every version of a key, and compaction keeps versions for a retention period that you set. - Value separation, opt in, for values larger than 1 KiB, so that compaction does not rewrite large values again and again. - Encryption at rest, transparent, with AES-256-GCM or XChaCha20-Poly1305. - Differential testing against an in-memory reference model: 500 seeds of 5,000 steps each, 2,500,000 operations, in every CI run. Any divergence fails the run. What do the benchmarks show? With synchronous durability, every commit is flushed to disk before it returns. SurrealKV 1.0 delivered these results on 13 October 2026: | Engine | Point reads (OPS) | Creates (OPS) | Updates (OPS) | Deletes (OPS) | Scans (OPS) | |---|---:|---:|---:|---:|---:| | SurrealKV | 6,804,864 | 229,376 | 221,341 | 264,089 | 905,132 | | RocksDB | 855,851 | 8,568 | 36,263 | 32,043 | 852,661 | | SlateDB | 92,303 | 8,257 | 8,122 | 8,242 | 17,985 | Against RocksDB, SurrealKV is 7.95× faster on point reads, 6.10× faster on updates, 8.24× faster on deletes and 1.06× faster on range scans. Against SlateDB, which ran on local disk and not on object storage, it is 73.7× faster on point reads and 27.3× faster on updates. SurrealKV creates records 26.8× faster than RocksDB. RocksDB's create rate with synchronous durability is far below its own update rate of 36,263 operations a second, and we have not explained why, so this post does not headline it. The benchmark ran with crud-bench on an AMD Ryzen Threadripper 9970X (32 cores, 64 threads) with 128 GB of RAM and a 4 TB NVMe SSD. It used 500,000 keys, 48 worker threads and 128 clients. The harness runs SurrealKV with value separation on and a larger memtable than the engine's defaults. Each figure is a single run. Fjall, ReDB, LMDB and libmdbx are not in the table, because their runs with synchronous durability were too slow to finish at this dataset size. Where is RocksDB faster? Without synchronous durability, RocksDB is faster at writes. SurrealKV is 1.88× slower on creates, 2.22× slower on updates and 2.41× slower on deletes, and 8.26× faster on point reads. Without synchronous durability, the engines also make different promises about what survives a crash, so those figures measure speed and not safety. Only the synchronous-durability table compares engines that each flush before acknowledging. How do range scans compare? Without synchronous durability, SurrealKV scans the first 100 key-value pairs of the dataset 896,366 times a second. LMDB leads that scan at 1,192,772 scans a second, and RocksDB manages 851,848. The table shows scans per second over the same 500,000 keys, with 5,000,000 iterations of each scan. | Engine | Limit (OPS) | Keys, limit (OPS) | Skip + limit (OPS) | Keys, skip + limit (OPS) | Full count (OPS) | |---|---:|---:|---:|---:|---:| | SurrealKV | 896,366 | 2,313,942 | 96,365 | 98,612 | 402 | | RocksDB | 851,848 | 851,580 | 35,539 | 35,902 | 159 | | SlateDB | 26,187 | 26,266 | 7,460 | 7,477 | 87 | | Fjall | 132,698 | 151,861 | 4,335 | 4,383 | 42.4 | | ReDB | 561,837 | 571,629 | 44,438 | 44,462 | 249 | | LMDB | 1,192,772 | 1,195,166 | 549,220 | 552,090 | 902 | | libmdbx | 384,128 | 260,769 | 183,361 | 185,073 | 848 | - Limit (select(*) limit(100)) returns the first 100 key-value pairs of the range. Keys, limit (select(id) limit(100)) returns only the keys. - Skip + limit (select(*) start(5000) limit(100)) walks and discards 5,000 entries before returning 100. Keys, skip + limit returns only the keys. - Full count (count()) visits every key in the range. Against RocksDB, SurrealKV is 1.05× faster on the first 100 pairs, 2.72× faster on a keys-only scan of the first 100 entries, 2.71× faster on scans that skip 5,000 entries and 2.53× faster on full counts. SurrealKV leads every engine on the keys-only scan, at 2,313,942 scans a second. LMDB leads SurrealKV on the first 100 key-value pairs (1.33× faster), on scans that skip 5,000 entries (5.70× faster) and on full counts (2.24× faster). How much memory does SurrealKV use? SurrealKV has the lowest resting memory of the seven engines measured, at 221 MiB, against 590 MiB for RocksDB. Resting and peak memory are the lowest and highest process memory sampled across the whole benchmark run, without synchronous durability. | Engine | Resting memory | Peak memory | |---|---:|---:| | SurrealKV | 221 MiB | 1.79 GiB | | RocksDB | 590 MiB | 1.02 GiB | | SlateDB | 265 MiB | 2.73 GiB | | Fjall | 627 MiB | 1.71 GiB | | ReDB | 257 MiB | 2.17 GiB | | LMDB | 776 MiB | 826 MiB | | libmdbx | 40.98 GiB | 117.71 GiB | SurrealKV's peak memory of 1.79 GiB is higher than that of RocksDB (1.02 GiB) and LMDB (826 MiB), because parallel commits buffer active batches. The libmdbx figures are what the harness measured, and we have not investigated them. Where is the design written down? The SurrealKV whitepaper, "A Versioned LSM Engine with Radix-Tree Memtables and a Commit Ring", explains how SurrealKV reaches these numbers, what each design decision costs and what the measurements do not cover. How can you run the benchmark yourself? Every figure comes from one command on one machine. Run it on your own hardware: CRUD_BENCH_CONFIG=config/memory.toml ./run.sh -d surrealkv --no-build --optimised --sync -s 500000 -c 128 -t 48 Change the -d flag to run a comparator, and remove --sync to run without synchronous durability. If you find a fairer configuration for a comparator, open an issue or a pull request on the crud-bench repository. SurrealKV is open source on GitHub. To use it in a Rust project, add the crate: cargo add surrealkv Speed or durability? Yes. Stop choosing.
SurrealKV 1.0: an embedded, snapshot-isolated LSM storage engine in Rust SurrealKV will be the persistent storage engine in SurrealDB 4, replacing RocksDB. It is an LSM-tree with MVCC and snapshot isolation, a lock-free asynchronous commit pipeline and optional value separation for large values. It includes skv, a tool that migrates existing RocksDB stores offline. On a 32-core, 64-thread AMD Ryzen Threadripper 9970X with 128 GB of RAM and an NVMe SSD, and with synchronous durability, reads are 8.0x faster than RocksDB and 73.7x faster than SlateDB (on disk, not object storage). Updates are 6.1x and 27.3x faster. That is 6.80 million point reads per second across 500,000 keys. Repo, benchmark commands and whitepaper: Github. Questions and feedback welcome.
Our commitment to open source: show the code, run the numbers Author: Tobie Morgan Hitchcock We commit to three things: show the code, run the numbers, and say what we did not measure. SurrealKV and SurrealMX are open source under Apache 2.0, SurrealDB is source available under the Business Source License 1.1, and every benchmark we publish comes with the command, the hardware and the method behind it. A database is a trust relationship. It holds your data, it decides what survives a crash, and it decides who can see what. Infrastructure that agents depend on, running unattended at a scale nobody can supervise, has to earn that trust in a way anyone can check. This post sets out how we intend to earn it. Why does SurrealDB publish its code? A claim about a database is only worth what you can check. There are three ways to check ours: read the code, run the benchmark, and read the paper that explains the design and its limits. We publish all three. That is why you can read the SurrealDB source, why the two new storage engines are open source, and why every benchmark we publish comes with the command to run it. When a database tells you it is fast, correct or safe, you should not have to take its word for it. What does source available mean? We use two terms and keep them apart. - Source available means you can read the code and run it yourself, under a licence that restricts some uses. - Open source means an Apache 2.0 or MIT licence with no such restriction. SurrealDB is source available. It is released under the Business Source License 1.1, which is free for internal use and converts to Apache 2.0 after four years. SurrealDB Cloud and Enterprise Edition are commercial products. Everything this post calls open source is under Apache 2.0 or MIT. What is open source today? | Project | Licence | What it is | |---|---|---| | SurrealKV 1.0 | Apache 2.0 | A persistent storage engine: a log-structured merge-tree with snapshot-isolated transactions and optional versioned trees, built on a concurrent adaptive radix tree memtable and a commit ring. It will be the only persistent storage engine in SurrealDB 4. | | SurrealMX 1.0 | Apache 2.0 | An in-memory storage engine: multi-version concurrency control over a concurrent adaptive radix tree, with lock-free reads and optional persistence. | | crud-bench | Apache 2.0 | The benchmark harness behind every performance number we publish. | Our SDKs and tools, and many of the libraries beneath SurrealDB, are also open source under Apache 2.0 or MIT. The full list is at surrealdb.com. Each storage engine has a whitepaper. It explains how the engine reaches its performance, what we measured, and what we did not. We will also publish accompanying technical or academic papers for a number of our product launches. What stays open source? The storage engines, our SDKs and tools, and the libraries listed at surrealdb.com stay open source, under Apache 2.0 or MIT. How can I run the benchmarks myself? Every performance number we publish comes from crud-bench, on one machine: an AMD Ryzen Threadripper 9970X (32 cores, 64 threads) with 128 GB of RAM and a 4 TB NVMe SSD. The same harness and the same command run each comparator, so a number and the number it is compared with are measured the same way. We say what we compared. When an engine runs in memory, we say it runs in memory. When we compare against an engine on disk, we say it is on disk. SurrealKV runs with synchronous durability, against RocksDB, SlateDB (on disk, not object storage), Fjall, ReDB, LMDB and libmdbx: CRUD_BENCH_CONFIG=config/memory.toml ./run.sh -d surrealkv --no-build --optimised --sync -s 500000 -c 128 -t 48 SurrealMX runs against LMDB and RocksDB, both in memory: CRUD_BENCH_CONFIG=config/memory.toml ./run.sh -d surrealmx --no-build --optimised -s 15000000 -c 128 -t 48 Change the -d flag to run a comparator. Run it on your own hardware. If you find a fairer configuration for a comparator, or an engine we should have included, open an issue or a pull request on crud-bench. A benchmark that only we can run is not a benchmark. Whose work does SurrealDB build on? None of this started with us. SurrealKV belongs to the line of log-structured merge-trees that runs from Bigtable through LevelDB and RocksDB, and we compare it against them. SurrealMX builds on the adaptive radix tree and on the multi-version designs of Hekaton and Silo. Those ideas were published by people who let strangers read their work, and several of the engines we compare against are open source. We owe that openness a return. The whitepapers cite what we learned from. What will you hold us to? Three things. - Show the code. The engines and tools above stay open source. - Run the numbers. Every benchmark ships with its command, its hardware and its method. - Say what we did not measure. Each whitepaper lists what its measurements leave out, and we will keep doing that. Hold us to them. If we fall short, tell us. Looking forward We want infrastructure that anyone can inspect and anyone can challenge. Agents change what a database has to do. They work in volume, they share state, they carry context from one session to the next, and they need to show their work. The launches from 12 to 16 October 2026 cover that stack from the bottom up: from the storage engine, to the database layer, to the collaborative primitives that enable agents to work at pace, and at scale. All of it sits on one database, SurrealDB, and every benchmark comes with the command to run it. That is the foundation. We will set out our full view of infrastructure for the agentic future in a separate post.