DEV Community: Mark Gyles

Agent memory benchmarks are baked

Mark Gyles — Thu, 15 Oct 2026 09:19:13 +0000

Every agent memory vendor publishes a benchmark score. While most of these scores are true, very few of them measure the same thing.

We read the test harnesses (the code that runs a benchmark), prompts, judge settings and per-question output files behind the published scores on BEAM and LoCoMo, two benchmarks for agent memory, and we did the same for our own. A memory benchmark score is the result of several choices: which model writes the answers, which model judges them, which prompts they get and which scoring rule turns the judgements into a number. Change any one of these and the score changes. Without them, a headline score is hard to interpret.

This post describes what we found when we ran SurrealDB Agent Memory on these benchmarks, what we changed in our own run, and every number behind our headline score, including the ones that lower it.

A score is a recipe

BEAM gives a memory system long conversations, up to ten million tokens, and then asks questions about them. An answering model writes each answer from what the memory system retrieves. For each question, the benchmark lists the points a correct answer must contain, called rubric items. A judge model scores each rubric item 0, 0.5 or 1, the question's score is the average of its items, and the headline is the mean across all questions.

Each step has settings that a vendor chooses. Who answers? Who judges? Does the judge see the question? Does the answering prompt know what kind of question it is? Does half credit count? How is event ordering scored?

While none of these settings is dishonest on its own, a headline score rarely says how they were set.

Five ways a score gets easier

All of these practices appear in published runs. The code and output files for each are linked from our benchmarks page.

1. The answering prompt includes parts of the answer. BEAM stores metadata with each question, such as the topics a correct answer has to put in order. Hindsight's April 2026 harness and Exabase's published prompt add fields from this metadata to the answering prompt. In Hindsight's own outputs, 66 of 70 event-ordering answers name every expected topic, and none of those topics appears in the question. HydraDB says it reused Hindsight's original prompts unchanged, and it has published no outputs.

2. The question category chooses the prompt. BEAM sorts its questions into categories, such as event ordering and instruction following. Hindsight, Exabase and Cognee choose an answering prompt based on the question's category, and Honcho sends instruction-following questions through a separate pipeline. In production, a memory system does not know in advance what kind of question it is about to answer.

3. The scoring rule gets more lenient. The BEAM paper scores event ordering with Kendall tau, a measure of how closely the answer's order matches the correct order. A rubric average only checks whether each event is mentioned, in any order. Mem0 and Cognee use the rubric average. We use Kendall tau, as the paper does. Event ordering is our lowest-scoring category, so this choice lowers our mean, but it is the only rule of the two that checks whether the order is correct, which is what the category exists to test. Scored by rubric average, the same answers would read 79.3% instead of 77.2%.

4. The retrieval budget grows. Mem0's headline on BEAM 1M (the version with conversations of one million tokens) gives the answering model up to 200 memories. Mem0’s own files show a score of 64.1% with 200 memories and 60.4% with 50. Our published run gives the answering model the top 50 memories.

5. On LoCoMo, the hardest questions are removed and the judge accepts near misses. LoCoMo groups its questions into five categories. Category 5 holds the adversarial questions, which cannot be answered from the conversation, so a correct response says that the information is not there. Following the Mem0 paper, most published LoCoMo scores leave this category out. Mem0's judge also counts an answer as correct when it gives one correct item out of a list, or a date up to 14 days away from the right one. In April 2026, an audit by Penfield Labs found that LoCoMo's judge accepted 62.81% of answers that were deliberately wrong but on the right topic.

The choice of models also affects the score. Most vendors use models from the same family to answer and to judge, and many use a stronger answering model than the original papers did. Some headline scores have no per-question files behind them at all.

Counting only full marks

A BEAM mean hides partial credit. A question where every rubric item gets half marks scores 0.5, and it raises the mean just as a correct answer does.

So we also counted something simpler: the share of questions where every rubric item got full marks. We call this the strict score. None of the vendors we compared publishes one, so we calculated it from their own per-question files wherever those files exist.

On BEAM 1M:

System	Headline mean	Strict	Answering model	Judge
SurrealDB Agent Memory	77.2%	57.1%	Gemini 3.8 Flash	Gemini 3.5 Flash Lite
Exabase	75.0%	48.0%	Gemini 3 Flash Preview	Gemini 2.5 Flash-Lite
Hindsight	73.9%	48.4%	Gemini 3.1 Pro Preview	Gemini 2.5 Flash-Lite
Mem0 (top-200)	64.1%	40.1%	GPT-5	GPT-5
Honcho	63.1%	41.4%	Claude Haiku 4.5	Claude Sonnet 4.5 (harness default)
HydraDB	82.0%	Not countable	Not stated	GPT-5.4

Every strict score we could count is between about 20 and 27 points below its headline mean. A gap of this size is expected, because the mean gives credit for answers that are partly correct. Publishing both numbers shows how much of each score comes from that partial credit.

Read the table as a record of how each score was produced. The rows use different answering models, different judges and different retrieval budgets, so they cannot be ranked against each other.

What we did in our own run

We followed the BEAM paper wherever we could, and we list every place where we did not.

Same judge prompt. The judge prompt is the official BEAM prompt. The judge model is Gemini 3.5 Flash Lite instead of the GPT-4.1 Mini that the authors' code uses, so the judge model is one of the ways our run differs from the paper.
Nothing extra in the prompts. The question category is never given to the answering model, and the judge sees the answer and the rubric but not the question.
Half marks counted, and shown separately. The mean counts 0.5 scores, as the paper specifies. The strict score of 57.1% counts only full marks.
Our own prompt and retrieval. The run answers with the product's own prompt and retrieval, instead of the paper's baseline prompt with the top 5 results.
Ten non-default settings. We switched on ten retrieval and chat settings that the product does not enable by default. Eight change retrieval: SPECTRON_RETRIEVAL_TURN_ORDER, SPECTRON_RETRIEVAL_CLAIM_CONFLICTS, SPECTRON_RETRIEVAL_GROUNDING_CHECK, SPECTRON_RETRIEVAL_EPISODIC_TREE, SPECTRON_RETRIEVAL_EVENT_DIGESTS, SPECTRON_RETRIEVAL_TREE_BREADTH, SPECTRON_RETRIEVAL_GROUNDING_PROVENANCE and SPECTRON_RETRIEVAL_TREE_ADAPTIVE_BUDGET. Two change how the chat answer is written: SPECTRON_CHAT_ANSWER_CONTRACTS and SPECTRON_CHAT_STANDING_INSTRUCTIONS.
Event ordering scored by Kendall tau. As in the paper, the score checks whether the order is correct. We score 49.7% in this category, and 1 of its 70 questions gets full marks.
Failures score zero. When a judge call fails twice, the rubric item scores 0, and a score outside the range 0 to 1 is clamped to that range. The BEAM reference code stops scoring the whole conversation instead.

On LoCoMo, our strict score is 75.8% across all five categories, including the adversarial one, over 1,986 questions. Under Mem0's own protocol, which leaves out the adversarial category and uses the more lenient judge, the same system scores 92.6% with GPT-5 answering and judging, and 90.1% with GPT-OSS 120B answering and GPT-4o judging. We publish all three numbers together so that readers can compare them directly.

Our 700 BEAM 1M answers are published on the benchmarks page, each with its question and rubric, so you can grade them with any judge you like. The harness commands are not public yet.

Be your own judge

Before you trust any memory benchmark score, including ours, ask five questions:

Which model answered, and which model judged?
Did the prompt know the question's category, or any part of the answer?
Does the headline include partial credit, and what is the strict score?
How much context did the answering model get?
Are the per-question files published, so that you can check the count yourself?

A score that comes with answers to all five can be checked. A score without them has to be taken on trust.

Every run, judge, protocol and vendor comparison is on our benchmarks page, with sources linked for every claim.

Introducing SurrealDB Agent Memory

Mark Gyles — Thu, 15 Oct 2026 08:51:50 +0000

Author: Tobie Morgan Hitchcock

AI agents have a memory problem: most of what they know lives either in the current context window, in local siloed memory solutions, or in an external retrieval system.

That works up to a point. But once an agent needs to remember information across sessions, distinguish current facts from old ones, understand relationships between entities, or explain where a fact came from, storing conversation history or embedding chunks into a vector database stops being enough.

Today, we’re introducing SurrealDB Agent Memory, a memory and knowledge layer for AI agents built on SurrealDB. It takes conversations, documents, and structured data and turns them into persistent, queryable memory: entities, attributes, relationships, instructions, source information, embeddings, and retrieval traces stored together in SurrealDB.

The goal is fairly simple: give agents persistent state that can change over time without losing track of what changed, when it changed, or why.

How we benchmark Agent Memory

Memory benchmarks are easy to quote and hard to compare. Scores can vary significantly depending on the answering model, judge model, number of retrieved results, and which settings are enabled. So we’ve published our results, methodology, and configuration on a dedicated benchmarks page.

On BEAM 1M, a long-term memory benchmark based on conversations of around one million tokens, Agent Memory scores:

77.2% mean score
57.1% strict accuracy, where an answer only counts if it is fully correct
82.9% of questions scoring at least 0.5

We report strict accuracy alongside the mean because partially correct answers can raise the average. Strict accuracy shows how often the system produced a fully correct answer, which is an important distinction for production use.

We also document where our run differs from the reference setup. The 77.2% result uses Agent Memory’s own retrieval and prompting pipeline rather than the paper’s top-5 baseline, enables ten retrieval and chat settings that are not on by default, and uses a different judge model from the authors’ reference implementation. Our weakest category is event ordering, at 49.7%. Temporal reasoning remains an area we are actively working to improve.

Our reporting follows four rules:

Name the models. Every result identifies both the answering and grading models.
Show strict accuracy alongside the mean. We don’t report only the more favorable aggregate.
Avoid ranking claims. Different models, judges, retrieval settings, and configurations can make leaderboards compare setups rather than systems.
Document every deviation. Any departure from the benchmark’s reference methodology is listed explicitly.

Where other vendors publish per-question results, we calculate strict accuracy from those files using the same method. The benchmarks page also documents eleven practices that can materially affect scores and shows which apply to each published result, including ours.

We’ll publish our per-question results and run configuration so the numbers can be independently checked. Results for BEAM 10M and LoCoMo are available on the same page.

From retrieval to structured, evolving memory

The simplest implementation of agent memory is to store previous messages, generate embeddings, and retrieve the most similar chunks when the agent needs context. That works for basic recall, but it becomes harder to manage as information changes over time.

If a user first says: "I work at Pied Piper as VP of Engineering" and later says: "*I’ve moved to Hooli as CTO", both statements may be relevant to the question “*Where does this person work?”. Similarity alone does not tell the system which one is current. SurrealDB Agent Memory treats this as a state-management problem, not just a retrieval problem.

When new information arrives, it is first extracted into structured memory such as entities, attributes, relationships, instructions, and uncertainties. That structured information is then reconciled against what the system already knows.

Reconciliation determines whether the new information should be added, update an existing fact, supersede an older one, or remain uncertain because sources disagree. So instead of storing a growing collection of disconnected chunks, Agent Memory maintains an evolving model of what is currently believed, what was true previously, and how that state changed over time.

This makes it possible to answer both: "Gilfoyle’s role now is CTO" and "Gilfoyle's role last year was VP of Engineering". The older fact is not deleted. It remains part of the historical record while the newer fact becomes current.

Every fact keeps its source

A useful memory system should be able to answer more than “What do I know?”. It should also be able to answer:"Where did I learn this?". Fact-bearing records in Agent Memory carry structured provenance. This can include the originating conversation or document, the location of the source text, the source type, its trust level, and lineage when a fact was derived from other information. This means an application can trace a stored fact back to the conversation turn or document passage that produced it.

That is useful when debugging an agent, but it also changes how applications can present answers. Instead of simply generating a response and hoping the retrieved context was correct, applications can expose the underlying sources that contributed to it. Agent Memory also stores retrieval, reconciliation, and response traces, making it possible to inspect which records were considered and how a stored belief changed.

Time is part of the data model

Facts often have more than one relevant timestamp. Something may have been true in January, mentioned in March, and stored by the database in April.

Agent Memory uses a tri-temporal model to distinguish different notions of time, including when information was valid in the real world, when the system knew about it, and the database's own transaction history.

This lets applications ask questions such as:

What is true now?
What did we believe last month?
What was true at a specific point in time?
When was this information corrected?

Without temporal modelling, older and newer facts tend to become competing chunks in the retrieval layer. With temporal state, the database itself can distinguish current information from historical information.

Documents and conversations in one graph

Agents typically need two types of information: authoritative knowledge (policies, documentation, repositories, product data, manuals, and other curated sources) and experiential knowledge (what users said, decisions made during previous sessions, preferences, observations, and things the agent itself has learned). Agent Memory stores both in one SurrealDB substrate rather than maintaining separate databases for documents, conversations, vectors, and relationships.

Because SurrealDB supports multiple data models in the same database, documents, entities, relations, embeddings, and traces can be stored and queried together under the same transactional system. That means a retrieval query can combine several different signals rather than requiring application code to join results from separate systems, improving accuracy, retrieval latency, and LLM token usage.

Retrieval is hybrid

Not every memory question is a semantic-search problem. Finding a paraphrased passage benefits from vector search. Finding an exact product ID benefits from full-text search. Finding something related to a particular customer, person, or project can benefit from graph relationships.

Agent Memory supports hybrid retrieval across these different signals. Vector similarity, full-text search, graph structure, and other ranking inputs can contribute to the same retrieval process. It also uses a tiered read path.

Simple questions can resolve directly against structured memory. Previously generated responses can sometimes be reused when the facts they depended on remain current. More complex questions can escalate to broader hybrid retrieval and model synthesis.

This is useful because asking “What timezone does this user prefer?” should not necessarily require the same retrieval and inference path as “Summarise everything relevant to this customer's current project.”

Memory has a lifecycle

Not everything an agent learns should remain equally important forever. Agent Memory separates three different operations:

Supersession handles information that has been replaced. The previous fact remains in history but is no longer current.
Decay reduces the importance of information as it becomes less relevant, while allowing frequently useful memories to be reinforced.
Forget removes information from the agent's active working set when explicit removal is required.

Keeping these concepts separate prevents a common problem where “old,” “wrong,” and “deleted” all end up meaning the same thing. They are not the same thing, and applications often need different behaviour for each.

Scoping memory to the right user, team, or agent

Memory is only useful if the agent retrieves the right information for the current situation. SurrealDB Agent Memory uses scopes to partition memory within a Context. A scope is a hierarchical path such as: org/piedpiper/user/gilfoyle or org/piedpiper/project/thebox. This lets applications decide which memories belong to an organisation, user, team, project, or another boundary that makes sense for the product.

For example, a customer-support agent might store company-wide policies at: org/piedpiper while Gilfoyle's preferences and previous interactions live under: org/piedpiper/user/hooli

When the agent is working with Gilfoyle, it can retrieve both the organisation-level knowledge and Gilfoyle's own memory without exposing another user's information. Session scopes are also propagated to the records created during that session, so new memories remain attributed to the right part of the application.

Scopes are different from permissions. Scope determines where a memory belongs; grants determine who is allowed to read or write it. Together, they provide a practical way to build multi-user and multi-tenant agents without maintaining a separate memory database for every user.

For stronger isolation, Agent Memory uses Contexts. A useful rule is: scopes partition data within the same application; Contexts separate entirely different memory environments.

Built on SurrealDB

Agent Memory runs as an application layer in front of SurrealDB. A Context provides the isolation boundary for a memory environment, with its own SurrealDB namespace and database. Within a Context, conversations, documents, entities, relationships, embeddings, traces, and other memory state live together.

Contexts are managed through SurrealDB Studio, where developers can work with conversations, inspect known entities, upload documents, explore the knowledge graph, and see what the system retrieved and learned during individual interactions.

Applications can integrate through the REST API, MCP, Python and TypeScript SDKs, or adapters for agent frameworks including LangChain, OpenAI Agents, and Vercel AI SDK.

A basic workflow looks like this:

Remember: Send a conversation turn, document, or fact to Agent Memory.
Extract: Convert unstructured input into entities, attributes, relationships, instructions, and other structured state.
Reconcile: Compare that information with existing memory and decide what is new, what changed, and where uncertainty exists.
Store: Write the resulting state, provenance, embeddings, relationships, and traces into SurrealDB.
Recall: Query memory through structured lookups or hybrid retrieval, scoped to the relevant user, agent, organisation, or application.

That creates a loop in which the agent's state can continue evolving between conversations instead of being reconstructed from scratch every time.

Memory as persistent application state

We think agent memory becomes much easier to reason about once it is treated less like a cache around an LLM and more like persistent application state. Agents need to know what is currently true, what used to be true, where information came from, which sources should be trusted, and how different pieces of information relate to one another. Those are fundamentally data problems.

SurrealDB Agent Memory brings those capabilities together in one layer: structured memory, document knowledge, graph relationships, temporal history, provenance, reconciliation, and retrieval, backed by SurrealDB.

The result is agents that do not simply retrieve previous text, but can can maintain a persistance, queryable shared memory layer of what it has learned - and update that layer as the world changes. Get started with Agent Memory or explore the documentation.

We are replacing RocksDB with SurrealKV 1.0

Mark Gyles — Wed, 14 Oct 2026 08:30:00 +0000

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.

Our commitment to open source: show the code, run the numbers

Mark Gyles — Tue, 13 Oct 2026 09:03:27 +0000

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/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 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

Mark Gyles — Tue, 13 Oct 2026 08:18:24 +0000

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.

SurrealDB Cloud is now available on Microsoft Azure

Mark Gyles — Thu, 17 Sep 2026 15:13:29 +0000

Author: Tobie Morgan Hitchcock

SurrealDB Cloud now runs on Microsoft Azure. Three Azure regions are live today - US East 2, Germany and Brazil - and the provider is now a choice you make alongside the region when you create an instance.

Until now every managed SurrealDB instance ran on AWS. That was fine if AWS was already where your workloads lived. If your organisation had standardised on Azure, it wasn't: a managed database on another provider meant a second cloud to review, a second network to connect and a second contract to negotiate.

One less cloud to get approved

Running on Azure puts the database inside the perimeter your security and procurement teams have already signed off. With Azure Private Link, instances are reachable over a private endpoint in your own virtual network, so traffic between your applications and your database never touches the public internet or crosses a provider boundary. That takes both the cross-cloud egress line item and the latency of that hop off the table.

For regulated workloads it also answers the residency question in the terms auditors actually ask about. German and EU customer data stays stored and processed in Germany; Brazilian data stays in Brazil, with more regions coming soon.

The controls are identical on both providers and in every region: SOC 2 Type 2, ISO 27001, GDPR, and encryption at rest and in transit. So are the mechanics. Every tier is available, from Free and development instances through to production and Scale, and instance types, versions, backups and the API all behave exactly as they do on AWS. Existing automation needs nothing more than the new region value.

Where SurrealDB Cloud runs

On AWS:

• US East (N. Virginia)
• US East (Ohio)
• US West (Oregon)
• Europe (Ireland)
• Asia Pacific (Mumbai)

On Azure:

• US East 2 (Virginia)
• Europe (Germany)
• South America (Brazil)

Get started

Create an instance in SurrealDB Cloud and pick an Azure region from the list. The Free tier costs nothing, so you can put a real instance in your own Azure region before you take anything to a review board.

If you are running SurrealDB in production and want high availability alongside in-region deployment, the Scale tier gives you multi-node, multi-availability-zone clusters.

A listing on the Azure Marketplace is coming soon, so you will be able to procure SurrealDB Cloud through the same channel as the rest of your Azure spend. In the meantime, if Azure is your standard and that is why you have been self-hosting until now, that trade-off is gone. Get in touch to talk through an enterprise deployment.

SurrealDB Cloud is now available in Frankfurt, Germany

Mark Gyles — Mon, 07 Sep 2026 10:11:28 +0000

Author: Tobie Morgan Hitchcock

SurrealDB Cloud can now be deployed in Frankfurt, Germany. The new region is live today - pick it from the region list when you create an instance.

For teams across the DACH region and continental Europe, this is a second European option and, for most of them, the closer one. Until now the nearest place to run a managed SurrealDB instance was Ireland, on the far western edge of the continent.

Latency and data residency for your workloads

Running in Frankfurt puts the database closer to your users across continental Europe, next to the interconnect that most European traffic already passes through. It also keeps German and EU customer data stored and processed in Germany, satisfying data-residency requirements that previously ruled out a managed deployment. All this while maintaining the same SOC 2 Type 2 controls, ISO 27001, GDPR, encryption and network isolation options as every other region. Agents gain twice over: the region removes the distance, and SurrealDB removes the fan-out. Vector search, graph traversal, full-text search and document reads all resolve in one query against one store rather than separate calls to a vector database, a search engine and a primary database.

Where SurrealDB Cloud runs

Frankfurt joins six other regions:

• US East (N. Virginia)
• US East (Ohio)
• US West (Oregon)
• Europe (Ireland)
• Europe (Frankfurt)
• Asia Pacific (Mumbai)
• South America (São Paulo)

Get started

Create an instance in SurrealDB Cloud and select Europe (Germany) as the region. Everything else - tiers, instance types, versions, backups - works exactly as it does elsewhere, so existing automation needs nothing more than the new region value.

If you are running SurrealDB in production and want high availability alongside in-region deployment, the Scale tier gives you multi-node, multi-availability-zone clusters.

SurrealDB Cloud is now available in São Paulo, Brazil

Mark Gyles — Mon, 07 Sep 2026 09:51:34 +0000

Author: Ignacio Paz

SurrealDB Cloud can now be deployed in São Paulo, Brazil. The new region is live today - pick it from the region list when you create an instance.

For teams building in Brazil and across Latin America, this closes the last big gap in the deployment story: until now the nearest place to run a managed SurrealDB instance was North America, and every query paid for the trip.

Latency and data residency for your workloads

Running in São Paulo puts the database closer to your customers for our South American users. It also keeps Brazilian customer data stored and processed in Brazil, satisfying data-residency requirements that previously ruled out a managed deployment. All this while maintaining the same SOC 2 Type 2 controls, ISO 27001, GDPR, encryption and network isolation options as every other region. Agents gain twice over: the region removes the distance, and SurrealDB removes the fan-out. Vector search, graph traversal, full-text search and document reads all resolve in one query against one store rather than separate calls to a vector database, a search engine and a primary database.

Where SurrealDB Cloud runs

São Paulo joins five other regions:

• US East (N. Virginia)
• US East (Ohio)
• US West (Oregon)
• Europe (Ireland)
• Asia Pacific (Mumbai)
• South America (São Paulo)

Get started

Create an instance in SurrealDB Cloud and select South America (Brazil) as the region. Everything else - tiers, instance types, versions, backups - works exactly as it does elsewhere, so existing automation needs nothing more than the new region value.

If you are running SurrealDB in production and want high availability alongside in-region deployment, the Scale tier gives you multi-node, multi-availability-zone clusters. The Cloud documentation covers the full set of options.

Deploy in São Paulo.

How Cobrainer built graph-based agent memory on one engine

Mark Gyles — Mon, 07 Sep 2026 09:32:35 +0000

Author: Ignacio Paz

An AI agent is only as useful as what it can remember - and how well it can connect the things it remembers. Most teams hand their agent a memory by reaching for a vector store: embed everything, retrieve by similarity, hope the relevant context comes back. It works, until you notice the agent keeps surfacing things that are near the question but not actually connected to it.

Cobrainer, a skills-intelligence company based in Munich, took a different route. They gave their AI agent a memory that lives in the database as a graph, where the agent builds the relationships between nodes as it goes. They did it without adding a graph database, a vector engine, or a search engine to their stack. It all runs on SurrealDB, alongside a Rust-native agentic graph RAG built on the same store.

Here's how, and why a single engine made the difference.

The problem with flat memory

Cobrainer runs a skills-intelligence platform - the kind of system that reasons about how people, roles, skills, and capabilities relate to one another. That's an inherently graph-shaped problem. But their first retrieval setup wasn't graph-shaped at all.

It pulled context through flat vector retrieval over an S3-and-OpenSearch pipeline, which carried two recurring costs:

Accuracy. Flat vector matches returned context that was loosely related - semantically near, but not necessarily connected in any meaningful way. The team wanted the agent to follow real relationships between entities, so its answers were grounded rather than approximate.

Tokens. Broad vector matches meant stuffing a lot of marginally relevant context into every prompt - expensive, and more so with every call. The team wanted to fetch only the context that mattered.

The obvious fix - adding a graph database on top of the vector and search systems they already ran - would have meant more infrastructure to operate. For a startup moving fast, that fragmentation was the thing to avoid, not embrace.

What they wanted instead

Cobrainer's requirements were less about any single feature and more about not paying a tax for combining them.

• An agent and a graph RAG on one store: an AI agent whose memory lives in the database as a graph, plus an agentic graph RAG. Both are backed by a single engine for graph, vector, and full-text.

• A self-building memory graph: rather than hand-modelling every relationship up front, the agent should make use of the relations between nodes that it builds automatically as it works.

• Grounding through structure: retrieval that traverses real relationships, so answers are anchored in how things actually connect.

• Token efficiency by design: pull the relevant subgraph, not a broad similarity sweep.

• Pace: stand up new storage patterns quickly, without long migrations slowing the team down.

Why did Cobrainer choose SurrealDB?

SurrealDB gave Cobrainer graph, vector, and full-text in a single engine, all queried through SurrealQL - so the agentic use case didn't need pgvector or OpenSearch sitting alongside their database. (Their existing RDS Postgres stayed exactly where it was, doing the job it already did well.)

A few things made the build land the way they wanted:

One engine, queried one way. Documents, graphs, vectors, and full-text all live in one store - schemaless and schemafull side by side - and all reachable through SurrealQL. The agentic case added no new systems to operate.

Graph-based agent memory that builds itself. SurrealDB stores the agent's memory and its session checkpoints. As the agent works, it automatically creates the relations between the nodes it writes - so the memory graph forms on its own, and the agent can later traverse those connections instead of re-deriving them. The team described a multi-layered, graph-based memory model, and the thing that surprised them was how fast it came together.

A Rust-native agentic graph RAG. Cobrainer built the graph RAG natively in Rust on SurrealDB's Rust SDK, combining graph traversal and vector similarity in a single query. That's the piece that replaced the old S3-and-OpenSearch RAG - letting the agent walk relationships and rank by similarity in one round trip instead of orchestrating across services.

Managed, and inside the EU boundary. Because this is HR data, residency isn't optional. SurrealDB Cloud let a lean team run the engine as a managed service with EU-region data residency, keeping everything inside the boundary they're required to maintain.

The results

Cobrainer went from evaluation to a customer-facing production deployment in roughly three months. As of August 2026, that deployment is live. Measured against their previous S3-and-OpenSearch pipeline, the team reports three changes.

• Better accuracy: grounding the agent in real graph relationships, rather than loose vector matches, made its responses more reliable.

• Lower token cost per call: fetching only graph-relevant context - instead of a broad vector sweep - trimmed the tokens going into each prompt.

• A flexible platform for what's next: graph-based agent memory and a Rust-native agentic graph RAG, both on one engine, ready to absorb new use cases without another round of stack expansion.

"As a startup, we didn't want to fragment our stack every time we add a capability. For our agentic graph RAG, the alternative was weighing Postgres with pgvector and search extensions against bolting on OpenSearch - instead we got graph, vector, and full-text from one engine. What surprised us was how quickly we stood up a multi-layered, graph-based memory model for our AI agent, with SurrealDB handling its memory and session checkpoints. And SurrealDB Cloud kept all of it inside our EU data boundary."

Daniel Alker, Senior Cloud Platform Engineer, Cobrainer

The takeaway

Giving an agent a memory doesn't have to mean giving it another database. Cobrainer's story is a small proof of a larger idea. When one engine handles graph, vector, and full-text together, and the agent can build its own memory graph on top of it, the "right" architecture stops being a collection of specialised services. It starts being a single query.

Start with SurrealDB Cloud or explore the docs.

Graph engineering is missing a graph

Mark Gyles — Thu, 13 Aug 2026 13:08:08 +0000

Author: Tobie Morgan Hitchcock

Graph engineering is having a moment.

The definition going round is a good one, and I am not going to try to redefine it. Complex agents increasingly look like graphs: nodes do the work, edges decide what happens next, state moves between them. That is real, it matches what production actually looks like, and the people saying it are right.

Almost nobody makes the next observation. Those agents are still fed context from flat vector chunks, a separate document store, a relational database and some ephemeral session memory. While the execution architecture became a graph, the data architecture underneath it did not.

Graph engineering is not just about graphing the agents. You also have to graph the context they operate on.

Or, less politely: you cannot graph-engineer the agent and leave its memory as a pile of chunks.

This is my attempt to say what graph engineering has to mean if it is going to outlive the meme.

The rename cycle

We have been renaming the same struggle for a few years. Prompt engineering optimised instructions. Context engineering optimised what goes into the window. Harness engineering, loop engineering, and now graph engineering optimise how agents work together.

I do not mind the labels. They appear when builders hit a wall. This wall is real. One agent loop in one chat window stops scaling the moment the work looks like a team: parallel reviewers, a fixer, a security check with veto power, a human gate before anything irreversible. That structure is a graph. It always was.

Every one of those renames moved up the stack, and every one of them left the data layer where it was.

Two graphs. Say which one you mean.

When someone says graph engineering, they could mean one of three things and rarely say which:

A graph of loops, which is really a claim about control flow: what you get when one loop stops being enough.
An execution graph.
A context graph.

The loop graph folds into the execution graph, so two are left standing, and most threads blur even those. Sometimes people mean both. They almost never say so.

The execution graph

What runs next, in what order, with what rights. It determines what your agents do.

Nodes are work: a classifier, a tool call, a coding agent, a reviewer. Edges are transitions: success, fail, escalate, fan out. State is the scratchpad the system mutates. Verifiers sit on a separate path when the stakes are high. Stop rules exist so the thing does not burn tokens until the card declines.

This is a state machine with probabilistic nodes inside it. LangGraph made the case earliest and loudest, and Google's ADK, Mastra, CrewAI, Microsoft's agent frameworks, or a boring job runner you wrote yourself all live on the same plane. Useful, necessary for a lot of production agents, and on its own not sufficient.

The context graph

What is true, what is related, what was true when, and who said so. It determines what your agents know.

Here the nodes are entities, documents, events, users and assets, and the edges between them carry properties of their own: since, confidence, source. Provenance, time, permissions and hybrid retrieval all matter, because the world is not only triples and it is not only embeddings.

Classic knowledge graphs and GraphRAG both sit on this plane. It gets a paragraph in most threads and a whiteboard in almost none.

So:

The execution graph engineers the graph of work. The context graph engineers the graph of knowledge.

Most teams have engineered the first and are still running the second as a pile of chunks in a vector store.

Where they meet: the turn

Every serious agent turn is three moves: read, think, write. Read means traverse relations, pull vectors, load history and permissions. Think means the model reasons over a complete packet, not three partial dumps from three systems that disagree with each other. Write means decisions, new entities, and memories land somewhere the next turn can actually see them.

If your execution graph is elegant and your write path is "maybe the vector DB, maybe the graph DB, maybe a JSON blob in object storage," the whiteboard never became system truth. You choreographed forgetting.

That is the definition I use:

Graph engineering is how you design the execution graph of agent work and the context graph of durable knowledge, then keep them consistent across every turn.

The meme covers the execution graph. Production dies on the other two.

Loops, graphs, context. Stack them.

A loop is fine when one goal, one verifier, and one stop condition cover the job.

An execution graph earns its keep when you need parallel specialists, explicit escalations, or policy gates.

Context engineering is what you do on every node either way: put the right facts, tools, and state in front of the model at the right time. Widening the context window does not solve a wrong-context problem, it just raises the price of getting it wrong.

Harnesses and frameworks host all of this. I am not here to sell you an orchestrator. We did not build SurrealDB to replace your control plane.

We built it because the existing data planes under those nodes were a mess.

GraphRAG is one chapter, not the book

People swap the words, but they should not.

GraphRAG is a retrieval pattern: extract structure from a corpus, then use the graph, and often community summaries, to ground generation. It is a good technique, and one node in a larger system can run it just fine. You can also run GraphRAG with almost no multi-agent workflow at all. Microsoft's own documentation makes the honest version of the argument: vector-only retrieval struggles when answering a question requires connecting information across relationships.

If graph engineering is going to mean anything durable, it is how the whole system moves, remembers, and stays correct. Retrieval is necessary, but it is not the architecture.

Retrieval is not three searches and a re-ranker

Almost everyone ships the same pattern. Fire a vector search. Fire a keyword search. Maybe fire a graph query. Take fifty from each, throw the pile at a re-ranker, keep what floats, stuff it in the prompt.

That pipeline has a structural flaw, and it is not latency. Each leg searches blind to the constraints the other legs know about. The vector index does not know this question is about one customer's contracts; it knows only that a question-shaped vector is near some passage-shaped vectors. So it returns fifty candidates and hopes. The keyword leg does the same. The graph leg returns a neighbourhood with no idea which parts are relevant to the sentence that was asked. Then a re-ranker, which can see the text and none of the structure, is asked to reconcile three lists that were each built without the others' information.

You over-fetch because that is the only defence against three blind legs. Over-fetching grows your token bill. Then you pay a second time, because the pile you carried back is mostly padding, and padding in the context window is not free: it costs money on the way in and accuracy on the way out, since a longer prompt gives the model more chances to ground its answer in the wrong sentence.

Run the similarity inside the traversal rather than beside it.

If embeddings are a field on the entity, and full-text indexes sit on the same rows, and relations are edges between those same rows, then one query expresses the whole thing: start from what the question is about, walk the relations that matter, and score by similarity and text relevance as you go, with permissions and time bounds applied in the same pass. Roughly:

SELECT
    id,
    name,
    ->stated_by->source AS provenance
FROM entity
WHERE ->works_at->company:acme
  AND valid_until = NONE
  AND embedding <|10, 40|> $question

The structure prunes before similarity scores, and similarity ranks within what the structure allows. You are not searching a corpus and hoping the answer's neighbourhood comes with it. You are searching a neighbourhood you already have reason to believe in.

That buys two things.

Fewer tokens. You stop over-fetching, because a constrained candidate set does not need a wide net to be safe. You carry back a small precise set instead of three large ones minus whatever the re-ranker threw away, and you stop paying for the same fact three times because three stores each returned their own copy of it.

Higher accuracy. Every filter that was inexpressible in the vector leg (this entity, this scope, this time window, this permission, currently true rather than superseded) becomes expressible, because it is evaluated in the same statement as the similarity. Constraints you could only apply after ranking are now applied before it.

Our own numbers say the same thing from the other direction. When we were first developing Spectron, our memory layer, we tried the obvious thing: reduce each extracted fact to a short sentence, embed it, and add it as another dense leg in the hybrid mix. It fixed roughly a hundred benchmark questions and broke roughly as many again, landing slightly negative and inside the noise. Meanwhile the two changes that clearly won were both structural: routing from a resolved entity into its typed facts, and expanding a hit into its conversational neighbours. Both worth a couple of points on their own.

The lesson we took: reducing a typed fact to a sentence and matching it by cosine throws away exactly the structure that made extracting it worthwhile. A similarity list also cannot abstain. It always returns its k, so when the right answer is not there it returns something else with total confidence, and something else lands in the prompt. Structure can return nothing, which is frequently the correct answer.

A context graph is not an extraction job

The obvious objection: fine, so I bolt a graph database onto my stack and run an extractor over my corpus.

You can. What you get is a pile of assertions in a vocabulary the model improvised one turn at a time, and the difference shows up months later as retrieval that cannot find things you know are in there.

Here are the numbers from one conversation we ingested end to end. Of the attribute keys the extractor produced, 85% were used exactly once: 236 distinct keys across 325 facts, an average of 1.4 uses per key. Action verbs were nearly as bad, 80% used once. The two most common verbs in the whole set were shared_image and shared, describing the same act, counted separately.

Now consider what that does to a query. WHERE key = 'residence' finds nothing if this turn's extraction called it lives_in, and the next one called it home_city, and a third called it current_residence. The structured path, the one that was supposed to make the graph worth building, stays dark. Retrieval falls through to similarity, and you are back to the pattern in the previous section, paying for a graph you cannot query.

The interesting part is the control case. One relation family in that same measurement was not fragmented: 4.3 uses per label instead of 1.4, only 40% singletons. It was the one family where the extraction prompt already showed the model the vocabulary the system had established, with an instruction to reuse an existing label and only mint a new one when nothing fits. Same model, same text, same run. The only difference was whether the graph told the extractor what it already knew.

A context graph is a loop with itself, not a function over text. Feed the established vocabulary back. Canonicalise predicates at write time so two spellings of one idea land in one bucket. Resolve mentions against entities that already exist, rather than minting a new node for every phrasing, because the same customer becoming five nodes means every traversal lies.

Some hard-won specifics, since this is where the work actually is.

There is no correct base form a priori. We tried folding inflections and the naive rules are landmines: strip a trailing e and care merges with car; undouble a consonant and roll merges with role; strip a trailing s and news becomes new. Any stemmer aggressive enough to bucket reliably produces non-words that then surface in your API responses. What worked was narrower and duller: only ever fold onto a spelling this graph already uses, never toward an invented lemma.

Semantic merging is a judgement about meaning, not a normalisation. home_city and city_of_residence probably mean the same thing. "Use metric units" and "always answer in metric" probably do too. Fold them wrongly and you have discarded something a user explicitly said. We left that undone deliberately, and said so, rather than pretending a string function had settled it.

Time is two axes and they are not the same axis. When a fact was stated is not when the thing happened. If you store one and render it as the other, "when did X happen" gets answered with when it was mentioned, confidently and wrongly. Relative phrases are worse: "last week" is a window, not an instant, and letting the answering model do calendar arithmetic at read time from whatever dates happened to be in its context is exactly the failure you are trying to remove. Resolve at write time, against the source's own date, and store what was actually stated. Store nothing when nothing was stated, so that "no event time" and "the event time equals the ingest time" stop being the same value.

Dates do not belong in the text you embed. We had resolved windows interpolated into the fact sentence that was both the keyword document and the embedded vector. Those date tokens say nothing about what the fact means, and they pollute the retrieval key for every query. Dates live in columns. Renderers read columns. Text and columns cannot disagree if there is only one copy.

Half of what extraction produces is not linked to anything. In our measurement, 52% of action objects were free text rather than a resolved entity: the graph recorded that somebody did something to a string. That string is invisible to traversal. Extraction reported success. The graph got nothing it can walk.

An edge nothing reads is not memory. We shipped an alias edge, wrote a careful writer for it, and then pulled it, because no retrieval path traversed it. It was structure with no consequence.

All of this decides whether the context graph means anything. Meaning cannot be extrapolated from a graph that was never normalised, because the meaning was discarded before the write. And none of it is a one-time import: entity resolution and temporal invalidation are standing jobs, running every turn, or "what is true" decays into "what was true in March."

What actually breaks

Skip the forty-agent overnight graph. That is how you max a bill and learn nothing.

Here is what fails.

State lives only in the transcript. You cannot debug it, audit it, or resume it cleanly if that is the only place it lives. IDs, permissions, and intermediate facts need a home outside the prompt.

Everything is agentic. Money movement, PII, deletes, external side effects: those edges should be code, not model judgement. Give the model freedom where exploration actually pays off, and encode the paths you already know are correct.

Verifiers share the same spoiled context. Agents on the same model, reading the same flawed packet, agree with each other at industrial scale, which is why verifier context needs to be separated and drawn from evidence outside the graph: tests that ran, money that moved, a human weighing in before the expensive push. Organised nonsense is still nonsense.

You drew a DAG and production needed cycles. Retries, clarification, a human pausing and resuming the flow: these are not a design smell, they are how work actually works.

Your context graph is a pile of triples with no ontology. Model the domain before you extract at scale. Schema is what stops you from lying to yourself about what the graph actually means, not overhead for its own sake.

Extraction is stateless. Every turn invents its own vocabulary because nothing showed it the vocabulary that already exists. This is the single cheapest thing to fix and the one most people have not fixed.

The graph is built once and never maintained. Extraction is the easy day. Entities need resolving, or the same customer becomes five nodes and every traversal lies. Facts need expiry, or superseded beliefs sit next to current ones and both look true.

Retrieval is three searches and a re-ranker. Each leg is blind to the others' constraints, so you over-fetch to compensate, pay for the same fact three times, and hand a re-ranker the job of guessing what the query planner should have known.

Write-back is optional. The agent learns a preference, a failed approach, a new link between entities. If that write is not durable and visible under the same permissions as the read, the next node is guessing again.

No stop rule. Parallel agents without token, time, and tool budgets will happily burn through a budget without producing anything you can point to.

The shape everyone ships

Most "graph engineered" demos still look like this:

Four taxes, every time.

Context leaks at the seams. Relationships, history, and metadata fragment whenever they cross a boundary.
The same fact enters the prompt three times, and you pay for it three times.
No query can be planned across the whole picture, so every retrieval is a wide guess narrowed after the fact.
Ops multiplies: five configs, five monitors, five failure modes, and the glue quietly becomes the product.

You want the context graph and the durable data to be one thing. A context graph that cannot hold your application records, your documents, your vectors and your temporal state is a copy of your real data that you will spend the next year syncing.

This is why I flinch when graph engineering is reduced to "use a graph database." A graph-only store solves a real slice, but agents need documents, vectors, time, session state, and above all the ability to ask one question that is simultaneously a traversal, a similarity search and a filter. Split those across stores and that question stops being expressible at any price.

What this looks like inside a bank

Most of the graph-engineering conversation right now is about routing and reliability: how do I get five agents to hand work to each other without falling over. That is a startup's version of the problem.

Ask the same question inside a bank, an insurer or a global enterprise and the requirements change shape entirely. Every enterprise conversation I have had this year has landed on some version of the same list.

Shared context, not per-agent context. Twenty agents across four teams need the same view of the same customer. If each one has its own vector store, you do not have twenty agents, you have twenty inconsistent opinions with an org chart.

Permissions that travel with the data. Not permissions checked at the API gateway and then discarded. If retrieval cannot enforce who may see which fact inside the query itself, then every prompt is a potential exfiltration path and every new agent is a new review.

Provenance carried on the facts themselves. Who said this, in which document, on what date, and is that source still authoritative. "The model said so" is not a defensible answer when the fact ends up in a regulatory filing.

Auditable retrieval. Not just what the agent answered, but what it read to get there, and why those rows and not others. A re-ranker's opinion over three fused lists is close to unexplainable. A query with predicates in it explains itself.

Underneath all of it sits temporal truth: what did we believe on the day the decision was made, not what do we believe now. In a regulated firm the record exists to answer that question, which means facts need validity intervals and reads need to resolve as of a point in time rather than as of now. And the graph needs a boundary in both directions, with control over what is allowed into it and over what is allowed out of it into a prompt.

None of that is served by a prettier flowchart, and none of it is served by a vector store with a metadata filter bolted on. It is served by the context graph being a real database: transactional, permissioned, temporal, and auditable. The current discourse is not covering this, and it is what enterprises are buying.

What we set out to build

I am biased. I will say that up front.

We built SurrealDB as a multi-model engine: documents, graphs, vectors, time-series, full-text, relational, and auth in one system with one query language over them. The reason has nothing to do with graphs being fashionable. It is that the useful query is almost never one shape. It is "things related to this, that resemble that, that were true then, that this user may see," and every system that stores those four facts separately can only answer it by approximation and reassembly.

On the context side that means schema as ontology. Edges carry confidence, time, and source as fields rather than afterthoughts. Vectors live on the entities they came from, so similarity is an operator inside a traversal rather than a separate service you join against afterwards. Traversal, similarity, full-text, and filters resolve in one statement, planned together, instead of three round trips and a sync cron you forgot about until it pages you at 2am. Write-back lands transactionally under the same permission model you read from, which matters, but it is the floor rather than the pitch.

Spectron is the memory layer we built on that engine: entity extraction, predicate normalisation, entity resolution, temporal facts, and hybrid retrieval that is one query rather than three. Most of the engineering effort there has gone into what happens between the text arriving and the graph existing, rather than into retrieval algorithms. When the session ends, the context window forgets, but the system should not.

We are also building the comparison, because I would not take my word for it either: the same multi-agent application twice, once on an orchestrator plus a vector store plus a relational database plus a session cache, and once on the same orchestrator with a single context graph underneath. Same agents, same tasks, same model. Measured on context accuracy, tokens consumed, latency, network hops and lines of glue.

The control plane stays yours. We are complementary on purpose. The question I would ask is not whose orchestrator you use, but whether your retrieval can express a traversal and a similarity search in the same breath, and whether anything understood your data before it became a graph.

A checklist I would actually use

Scope

One recurring job with a real success metric, not a general assistant.
Someone owns the ontology, someone owns the workflow, and early on that can be the same person.

Execution graph

Label nodes: code / single LLM call / tool / full agent.
Edges only where work actually flows.
A verifier path with fresh context for high-risk output.
A human gate on irreversible actions.
Explicit stops and budgets.
Cycles where retries and clarification are real.

Before the context graph exists

Entity and relation types written down before bulk extraction.
Extraction shown the vocabulary the graph already uses, with an instruction to reuse it.
Predicates canonicalised at write time, folding only onto spellings the graph already has.
Mentions resolved to existing entities, with the unresolved rate measured rather than assumed.
Event time and mention time stored as separate columns, resolved at write time, absent when nothing was stated.
Nothing in your embedded text that is not part of what the fact means.

Context graph

Provenance on facts and edges.
Temporal validity, and a job that actually retires superseded beliefs.
A retrieval path that constrains before it ranks, explainable in one sentence.
Write-back after every turn for memories, entities, decisions.
Permissions enforced inside retrieval, not at the gateway.
Graph statistics on a dashboard: predicates per fact, unresolved mentions, duplicate entities. If you cannot see fragmentation, you will not fix it.

Reality checks

Outside-the-graph evidence for ship decisions.
Evals that include multi-hop and time questions.
Cost and latency budgets per node type.
Replayable state when something fails.

Grow the graph when the work forces you, not when a meme does.

What I would ignore

Renaming your orchestrator and calling it strategy.
Forty agents overnight.
Treating GraphRAG, context graphs, and execution graphs as the same slide.
Bigger context windows as a substitute for structure.
A better re-ranker as a substitute for a query that could have been planned properly.
Holy wars about anyone's database. The architectural gap is enough, and the market does not need another feud.

Closing

Graph engineering became the new buzzword because one chatty loop is not enough for real work. Good. Draw the execution graph. Be honest about where the model decides and where code decides.

Then do the half most threads skip. Understand the data before you write it: one vocabulary, resolved entities, real event times, facts that expire. Put the vectors on those entities rather than in another system, so retrieval is one query that traverses and ranks together instead of three searches arguing through a re-ranker. Make permissions and provenance properties of the data rather than of the API in front of it.

The label will get renamed again. It always does, and I would not build a roadmap on the word. But the two graphs are not a naming fashion. Every serious agent system has an execution graph and a context graph whether or not anyone drew the second one, and the gap between them is where the accuracy goes, where the token bill comes from, and where the audit fails.

Frameworks draw the graph of work. Something has to hold the graph of knowledge, keep it true, and survive the write-back. That is the problem we set out to solve with SurrealDB, and with Spectron, the memory layer we built on top of it. If your agent topology is getting serious and your context layer is still five separate systems you are hoping stay in sync, that is the seam to fix.

Introducing Scale: SurrealDB Cloud, built for high availability and scale

Mark Gyles — Thu, 02 Jul 2026 15:53:29 +0000

Author: Tobie Morgan Hitchcock

Today we're launching Scale, a new tier of SurrealDB Cloud built for the workloads you can't afford to have go down.

Our first tier, Start, was designed for building and shipping fast. Scale is designed for what happens next: production traffic, uptime commitments, and the kind of resilience your users never notice because there are always available nodes. It's the tier for teams running SurrealDB as the scalable context layer behind real applications and AI agents in production.

What you get with Scale

Scale is about one thing: keeping your database available and consistent under real-world conditions.

Highly-available, fault-tolerant clusters. Scale runs your database as a multi-node cluster designed to survive node and infrastructure failures without dropping writes or losing consistency. A single point of failure is no longer a single point of downtime.

Multiple availability-zone deployment. Your cluster is distributed across multiple availability zones, so even the loss of an entire zone doesn't take your database with it. Traffic keeps flowing while the cluster recovers in the background.

Horizontal scale. As demand grows, Scale grows with it. Add capacity by scaling out across nodes rather than being capped by the size of a single machine. Start with three nodes, and keep adding to scale your application or agent's needs.

See more information about SurrealDB Cloud Scale architecture here.

Built on SurrealDS

Scale is powered by SurrealDS, SurrealDB's distributed storage engine and the foundation that makes all of this possible.

SurrealDS is a new generation distributed storage architecture, rethought from first principles. Instead of coupling storage to compute on a single box or to a proprietary cloud tier, SurrealDS embeds consensus directly in SurrealDB nodes and separates the two layers cleanly. Here's what that architecture gives you.

Architecture overview

Compute and storage separation. Scale compute for QPS and storage for capacity independently, so you provision for the dimension that's actually under pressure.
No single leader. Each availability-zone node writes locally, writes scale horizontally, and transactions commit once a quorum acknowledges them.
Multi-write nodes. Every write node in the cluster can accept and coordinate transactions - there's no bottleneck routing all writes through one leader.
Reduced operational overhead. Consensus is embedded directly in SurrealDB nodes, eliminating external coordination services.
Fewer network dependencies. A single broadcast replaces multi-hop coordination, reducing latency.
Lower latency than leader-based replication. With no single leader and each AZ node writing locally, transactions avoid the extra round trips of traditional leader-based systems.

Future roadmap

Several SurrealDS capabilities are on the near-term roadmap and will land in the Scale tier as they ship:

Object-storage backed. Persist transactional data directly to commodity object storage - storage costs drop and capacity scales far beyond any single disk.
Cross-region replication. Data flows through object storage rather than between nodes, significantly reducing data-transfer costs while keeping regions in sync.
Instant recovery. A crashed node restores from object storage, with recovery time almost instant regardless of dataset size.
Instant branching. Clone a petabyte-scale database in seconds for development, testing, or experimentation.

Get started

If you're running SurrealDB in production, or getting ready to, Scale gives you the availability and fault-tolerance your workloads need, on the storage architecture no one else has.

Explore the tier in SurrealDB Cloud, and dig into the engine underneath at SurrealDS.

SurrealDB is now available on the Nebius AI Cloud Marketplace

Mark Gyles — Thu, 18 Jun 2026 15:33:29 +0000

Author: Tobie Morgan Hitchcock

We're excited to announce that SurrealDB is now officially available on the Nebius AI Cloud Marketplace.

This launch reflects our commitment to meeting developers and AI teams where they build, and deepens our partnership with Nebius to make SurrealDB easier to adopt, deploy, and scale on one of the fastest-growing AI cloud platforms in the world.

Why Nebius?

Nebius is a full-stack AI cloud built for the demands of modern AI workloads. Powered by the latest GPU and high-performance networking infrastructure, with managed platform, serverless AI, and storage built for the entire AI lifecycle, Nebius gives teams the infrastructure to train, tune, and serve models at scale.

As an NVIDIA Reference Platform Cloud Partner with infrastructure across Europe and the US, Nebius pairs bare-metal performance with the operational simplicity and cost efficiency that AI teams need to move from experiment to production. It's a natural home for SurrealDB - giving you a unified data layer right alongside the compute powering your AI and agentic applications.

Why SurrealDB?

SurrealDB combines document, graph, and relational capabilities in one unified database - designed for agent memory, context layers, modern applications, real-time systems, and AI-powered workloads.With flexible schema, SurrealQL, and built-in real-time features, SurrealDB enables you to build semantic and context layers powered by knowledge graphs for agent memory and multi-agentic workflows.

SurrealDB simplifies your technology stack, reduces Total Cost of Ownership and operational complexity, and allows you to ship products and features in days rather than weeks.

Get started

SurrealDB is available now on the Nebius AI Cloud Marketplace. We can't wait to see what you build, join our Discord community and let us know how you get on!