surrealdb

Our friends at @SurrealDB built a notes app on Phonon that analyzes your notes and reads the findings back to you, all on-device. Phonon, our on-device TTS + SurrealDB Agent Memory. Open source: surrealdb/surrealdb-gradium-phonon t.co

SurrealDB CVE-2026-121419 collapses MCP identities into one access method SurrealDB CVE-2026-121419 collapses MCP identities into one access method SurrealDB 3.1.0 through versions before 3.3.0 contains an authentication flaw tracked as CVE-2026-121419. The public record describes a collision in the MCP BoundSubject fingerprint: the fingerprint uses the access method name instead of the individual user identity for JWT or Bearer access. The result is described as an MCP session hijack. That sentence describes a subtle identity-design error. A session-binding value is supposed to answer "which principal is making this request?" If it answers "which authentication method was used?" then two users who authenticate with the same method can collapse into the same bound identity. Sessions need a principal, not a method MCP connects a model or agent to tools and data sources. A server may keep a session across multiple requests. The session must be tied to the authenticated principal, the client, and the authorization context. If the binding key is only jwt or bearer, the key distinguishes the mechanism but not the user. An attacker who can influence or reuse the binding may be able to continue a session under another user's context. The exact exploit path should be read from the vendor advisory and CVE record. The safe design principle is clear: identity binding must use a stable per-user value, not a label shared by every user of the same authentication method. This is similar to a cache-key mistake. Two different requests produce the same key and the cache returns the wrong object. In an authorization system, the "object" may be a user's session, privileges, or MCP tool context. Inventory MCP endpoints Identify every SurrealDB deployment that exposes an MCP integration. Record the version, authentication method, user model, token issuer, token audience, and session storage. Include development and staging instances because an agent test environment may still hold production credentials. Review how JWTs are validated. The server should check issuer, audience, expiry, signature, and token type. The session binding should include a per-user identifier that cannot be chosen by another user. If a token is anonymous or uses a shared service identity, the authorization model must say so explicitly. Map the tools that MCP can invoke. A database session may be able to query namespaces, modify records, or invoke functions. A stolen session is more dangerous when the agent has broad write access or can call administrative operations. Patch and rotate Upgrade to SurrealDB 3.3.0 or later. Verify the running version and the MCP listener configuration. If a public or shared endpoint is not required, remove it from the network path rather than relying only on user authentication. Rotate signing keys and sessions created during the exposure window. If the token issuer remains valid, an old token may continue to authenticate until it expires or is revoked. Review namespace and database permissions for the affected users. Test with two different users who use the same authentication method. Confirm that each session resolves to the correct principal and that one user cannot resume the other's MCP session. Test token replay, an expired token, and a token for the wrong audience. Monitor the agent boundary SurrealDB logs should connect MCP sessions to a user, token issuer, and tool call. Alert on a session that changes user context, a tool invocation outside the normal workflow, or a token used from an unusual network location. Do not put a long-lived administrative token in an agent's configuration. Use a dedicated service identity with narrow access. The MCP server is an authorization boundary between an automated client and the database, not a transparent proxy that should inherit every privilege. The patch corrects the BoundSubject collision. The operational review should make sure that the next identity label is not another shared string. References - CVE-2026-121419 public record - SurrealDB vulnerability record - SurrealDB security advisories

286 SurrealDB fingerprints and 1,479 title matches frame an identity-bound MCP review 286 SurrealDB fingerprints and 1,479 title matches frame an identity-bound MCP review ZoomEye returned 286 matches for app="SurrealDB" and 1,479 for title="SurrealDB" on November 4, 2026. The counts are close enough to invite a quick conclusion and different enough to require a careful one. SurrealDB CVE-2026-121419 affects versions before 3.3.0 and involves MCP BoundSubject identity collision for JWT or Bearer access. A public fingerprint can help find candidate instances. It cannot show whether MCP is enabled, which users authenticate, or whether the token binding is fixed. Observation | Query | Matches | |---|---:| | app="SurrealDB" | 286 | | title="SurrealDB" | 1,479 | The app query completed at 2026-11-04T23:44:59Z and the title query at 2026-11-04T23:45:01Z. Both used page 1, page size 1, and sub_type=all. The probes completed successfully. The title count is higher than the application fingerprint. A title may appear on documentation, a client UI, or a deployment that the fingerprint does not identify. The app count is a more specific product signal, but it still does not identify a version. What the counts support The counts support a discovery statement: SurrealDB has an indexed public footprint, and a title search finds more candidate pages than an application query. Neither number is a count of vulnerable databases. CVE-2026-121419 requires an MCP deployment with JWT or Bearer authentication and a vulnerable session-binding implementation. The external index cannot show those conditions. It cannot see the token issuer, the user identifier, the MCP tool configuration, or whether the server has been upgraded. Review the MCP identity path Inventory SurrealDB instances through internal configuration management first. Record the version, namespace, database, authentication methods, and MCP listener. Identify every agent or service that connects and the token or credential it uses. For each session, confirm that the binding key includes a per-user identity. A shared method label such as jwt is not a principal. Verify issuer and audience checks, token expiry, and revocation behavior. Map the tools the MCP server can invoke and the data each user can reach. Upgrade to 3.3.0 or later. Rotate signing keys and active sessions created before the fix. Test two users with the same authentication method and confirm that one cannot resume the other's session. Use external counts as a lead Treat the 286 application matches as a candidate list, not a vulnerability list. Resolve ownership and version through authorized systems. The 1,479 title matches may contain documentation and unrelated pages, so do not merge them into the same evidence set. The public measurement is useful for explaining why MCP identity review matters at internet scale. It is not a substitute for checking the version and token-binding behavior of an actual database. References - CVE-2026-121419 public record - SurrealDB security advisories - ZoomEye search platform

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.