surrealdb

2/10 SurrealDB keeps gaining traction as a multi-model doc+graph+realtime database. Curious how it holds up under real distributed load, but the developer story is genuinely appealing. surrealdb/surrealdb

SurrealDB: A scalable, distributed, collaborative, document-graph database, for the realtime web (33k stars) What it does All text below is quoted directly from the project README. >A scalable, distributed, collaborative, document-graph database, for the realtime web Key features of SurrealDB include: - Reduces development time: SurrealDB simplifies your database and API stack by removing the need for most server-side components, allowing you to build secure, performant apps faster and cheaper. - Multi-model: native multi-model support for document, graph, relational (enforcing schema and schemaless), time-series, geospatial and retrieval (full-text, vector, hybrid). This is offered natively through SurrealQL, SurrealDB's SQL-like intuitive query language. - Real-time collaborative API backend service: SurrealDB functions as both a database and an API backend service, enabling real-time collaboration. - Support for multiple querying languages: SurrealDB supports SQL querying from client devices, GraphQL, ACID transactions, WebSocket connections, structured and unstructured data, graph querying, full-text and vector indexing, and geospatial querying. - Granular access control: SurrealDB provides row-level permissions-based access control, giving you the ability to manage data access with precision. - Multi-row, multi-table ACID transactions - Single-node, or highly-scalable distributed mode - MCP (Model Context Protocol) server for LLM and AI-agent integration >Given that it's a single Rust binary, SurrealDB can run embedded (in-app), in the browser (via WebAssembly), in the edge, self-hosted as single backend node, or in a distributed cluster in the cloud. Repository surrealdb/surrealdb Repository stats |Metric|Value| |:-|:-| |Stars|33,170| |Forks|1,388| |Last release|v3.3.0 (2026-09-28)| |Languages|Rust 79.9%, SurrealQL 19.8%, Python 0.1%| |Contributors|186| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|cursoragent: 4, claude: 27| |AI co-authored commits|Claude: 27, Cursor: 4| Main contributor |Field|Value| |:-|:-| |Name|Tobie Morgan Hitchcock| |GitHub|@tobiemh| |Commits to this repo|2,630 (top contributor)| |Bio|Fullstack software engineer, and the creator of @surrealdb, the ultimate cloud database| |Company / Location|@surrealdb / London, UK| |Website|surrealdb.com| |X / Twitter|@tobiemh| |Followers|654| |Public repos|1| |On GitHub since|2012-03-29| ---------------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free

surrealdb: A scalable, distributed, collaborative, document-graph database, for the realtime web ★33156 surrealdb/surrealdb

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.

@petermattis @petermattis we took a lot of inspiration from Pebble, and even borrowed surrealdb/arenaskiplist to improve performance beyond what we were able to get initially (attribution to Andy Kimball is at the bottom of the README). We ended up settling on a surrealdb/artmap for that data-structure instead, because we were able to get better performance in Rust for the concurrency. One thing - this is a relatively small benchmark of course, because when comparing LMDB/libmdbx and the other rust based LSM trees it took a very long time to run the benchmarks, but we will run a much larger benchmark comparing just RocksDB and SurrealKV.

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.

Introducing SurrealMX: SurrealDB’s new in-memory storage engine Author: Tobie Morgan Hitchcock Today, we are introducing SurrealMX 1.0, our new high-performance in-memory storage engine for SurrealDB. SurrealMX is an embedded, transactional key-value engine with lock-free reads, designed for workloads where latency and throughput matter most. By keeping the working dataset in memory and combining multi-version concurrency control with a highly concurrent architecture, SurrealMX can process millions of operations per second while maintaining transactional guarantees. It gives developers a new storage option for low-latency applications, high-concurrency workloads, caching, temporary data, and applications where the dataset can comfortably reside in memory. Why we built SurrealMX Not every workload needs the same storage model. For applications where durability and datasets larger than memory are the priority, disk-backed storage makes sense. But there is another class of workloads where the main requirement is simple: make reads and writes as fast as possible (e.g. real-time applications, caching layers, ephemeral state, simulations, agent workloads, testing environments, and applications serving large numbers of concurrent requests). SurrealMX is designed specifically for these workloads. Instead of optimising a disk-backed database for in-memory use, SurrealMX starts with memory as the primary storage medium. This lets us remove much of the overhead that comes with disk-oriented architectures and design the engine around fast concurrent access. Built for performance SurrealMX combines a concurrent adaptive radix tree with multi-version concurrency control and a lock-free circular commit ring. The result is high throughput across reads, writes, updates, deletes, and scans. In our latest bare-metal benchmarks, SurrealMX delivered: | Engine | Point reads (OPS) | Creates (OPS) | Updates (OPS) | Deletes (OPS) | Scans (OPS) | |---|---:|---:|---:|---:|---:| | SurrealMX | 21,506,711 | 1,887,149 | 1,595,009 | 1,814,037 | 18,031,692 | | LMDB (in-memory) | 1,226,897 | 232,805 | 241,431 | 177,198 | 1,188,365 | | RocksDB (in-memory) | 759,060 | 616,649 | 572,246 | 705,773 | 836,666 | That translates to more than 21.5 million point reads per second, nearly 1.9 million creates per second, and over 18 million range scans per second. Compared with RocksDB configured for in-memory workloads, SurrealMX achieved approximately: - 28× higher point-read throughput - 3.1× higher create throughput - 2.8× higher update throughput - 2.6× higher delete throughput - 22× higher range-scan throughput The benchmark was run on bare metal using an AMD Ryzen Threadripper 9970X with 128 GB DDR5 RAM, across 15 million keys, 48 concurrent worker threads and 128 clients. Each figure is the best of three runs of that benchmark, for every engine. Designed for concurrency Modern applications rarely execute one operation at a time. SurrealMX is designed around multiple concurrent readers and writers without requiring a global lock. Its lock-free circular commit ring provides constant-time atomic slot claiming, while a sharded active-reader registry reduces contention between CPU cores. Reads can inspect version chains without taking locks, allowing the engine to scale more effectively as concurrency increases. For point reads, SurrealMX can also bypass transaction-pool checkout and reader registration entirely, returning the latest committed value directly. This architecture is particularly useful for applications where many threads or clients are continuously accessing and changing the same in-memory dataset. Transactions without giving up speed Being an in-memory database does not mean sacrificing transactional behaviour. SurrealMX supports full transactions, including rollbacks and savepoints, as well as both snapshot isolation and serializable snapshot isolation. Multi-version concurrency control allows transactions to operate against consistent snapshots while concurrent changes continue in parallel. For simpler workloads, direct operations such as get, set, put, delete and exists provide a lower-overhead path without requiring developers to manually manage transactions. That means applications can choose between convenience and more advanced transactional control while using the same engine underneath. Fast scans, without the allocation overhead In-memory analytical and retrieval workloads often involve more than point lookups. SurrealMX provides zero-allocation range scanning, allowing applications to inspect borrowed keys and values directly rather than repeatedly creating and copying objects. In our benchmarks, this helped SurrealMX exceed 18 million range scans per second. For workloads involving repeated retrieval over subsets of an in-memory dataset, reducing this allocation overhead can make a significant difference both to latency and CPU utilisation. In-memory first, with optional persistence SurrealMX is fundamentally an in-memory engine, and its fastest configuration keeps data entirely in memory. In this mode, data disappears when the process terminates. This makes it particularly well suited to workloads such as: - Caching and temporary state - Real-time application data - Development and testing - Simulations - Reconstructable datasets - Low-latency application state But some workloads need the speed of an in-memory database while still requiring recovery after a restart. For those cases, SurrealMX also supports optional persistence. Developers can configure append-only logging, periodic snapshots, asynchronous persistence, configurable fsync behaviour, and LZ4 snapshot compression. This makes durability a spectrum rather than an all-or-nothing decision. Applications can optimise for maximum throughput, maximum durability, or somewhere in between. Reliability under concurrency Highly concurrent database engines are difficult to test using conventional unit and integration tests alone. SurrealMX uses deterministic simulation testing: seeded, reproducible runs compared against a sequential reference model, to validate its behaviour across many interleavings of open transactions. The engine has been tested across 25 million simulated operations with zero divergences. Its persistence layer also protects transactions using checksummed append-only log frames. If a crash interrupts a write, recovery can distinguish incomplete data at the end of the log from valid committed transactions, ensuring transactions are recovered atomically rather than partially applied. Built for embedded and browser applications Like SurrealDB itself, SurrealMX is designed to operate in more than traditional server environments. It is an embedded Rust engine, meaning applications can run it directly inside their own process rather than communicating with a separate database server. SurrealMX also supports WebAssembly, opening the door to running an extremely fast transactional database directly inside browser-based applications. This makes it useful across everything from high-performance backend services to desktop applications and browser environments. SurrealKV and SurrealMX With SurrealKV and SurrealMX, SurrealDB now has storage engines designed for two different priorities. SurrealKV is our durable storage engine, designed for high-performance persistent workloads where data lives on disk. SurrealMX is our in-memory engine, designed for workloads where the entire dataset can remain in memory and minimum latency is the priority. Both are being built around the same principle: rather than treating storage as an external dependency, we can design the underlying engines around the workloads SurrealDB needs to support. That lets us optimise more of the stack ourselves, from the query layer all the way down to how data is stored and accessed. For more information, see our Deployment guide. A new option for low-latency SurrealDB workloads SurrealMX gives SurrealDB a storage engine designed specifically for the fastest end of the performance spectrum. With more than 21 million reads per second, millions of writes per second, lock-free reads, transactional guarantees, and configurable persistence, it provides a new foundation for applications where every microsecond counts. SurrealMX brings the full power of an in-memory transactional storage engine to SurrealDB - built for speed, concurrency, and the next generation of real-time applications. Go to the SurrealMX GitHub repository, read the whitepaper, or check out our Deployment guide for more information.

SurrealMX: a lock-free in-memory MVCC engine over a concurrent adaptive radix tree SurrealMX will be the in-memory engine in the next release of SurrealDB, and it is written in Rust. Reads never write to shared memory, so they keep scaling as you add cores. It supports serializable and snapshot-isolated transactions, can persist to disk, and runs embedded, in the browser and on a server. With both engines running in memory, it reads 28.3x faster than RocksDB and 17.5x faster than LMDB, and updates 6.6x faster than LMDB. On a 32-core, 64-thread AMD Ryzen Threadripper 9970X with 128 GB of RAM, that is 23 million point reads per second across 15 million keys. The absolute number moves with the hardware. Repo, benchmark commands and whitepaper: Github. Questions and feedback welcome.

28x faster than RocksDB on in-memory reads. Introducing SurrealMX v1 from @SurrealDB. A lock-free, transactional KV engine built for serious performance. Fully open source. Check out the benchmarks: surrealdb/surrealmx