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/opensource.
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/opensource 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 48SurrealMX 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 48Change 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.
