SurrealDB is a Rust multi-model database and context layer for AI agents: documents, graphs, vectors, time-series, and relations are native in one ACID engine, no stitched stores. Query with SurrealQL, connect via MCP, WebSocket, and SDKs, with GraphQL generated from your schema. Built-in auth, permissions, HTTP APIs, and live queries reduce separate backend glue. Runs embedded, at the edge, or as a highly-scalable cluster in the cloud. Same engine, everywhere.
This is the 2nd launch from SurrealDB. View more
Spectron
Launching today
Spectron is agent memory built on one ACID substrate. Graph, vectors, documents, and structured rows commit in one transaction. Every fact carries provenance. Corrections supersede, never overwrite. Hybrid retrieval fuses vectors, graph, BM25, and keywords. Traces feed back into ranking. Tri-temporal facts, multi-tenant scopes, and MCP support. No stitched stores. No sync pipelines.
Payment Required
Launch Team
the multi-model in one ACID transaction is the architectural claim worth pressure testing. most databases that support multiple data models achieve it through separate storage engines with a unified query layer, which means cross-model transactions have hidden consistency tradeoffs. curious whether the graph, vector, and document operations are truly atomic in a single engine or whether there's an abstraction layer underneath that introduces edge cases under concurrent writes
SurrealDB
Good question, @ansari_adin, and you've described the common pattern accurately; a lot of "multi-model" systems are separate engines behind a shared query planner, where cross-model atomicity is exactly where the bodies are buried.
SurrealDB is the inverse of that. There aren't separate storage engines per model; there's a single transactional key-value core, and documents, graph edges, and index entries are all just different key encodings over the same keyspace. A graph relation is a record, a vector or full-text index entry is a key maintained in the same write path, and so on. Because of that, a transaction spanning a document write, the edges it touches, and the index updates is one transaction over one keyspace under MVCC, not a coordinated commit across independent stores. There's no second consistency boundary hiding underneath to leak edge cases under concurrent writes. And every transaction has snapshot isolation consistency.
The interesting concurrency questions move to the layer you'd expect, which is the isolation and conflict-resolution semantics of that transactional core (and how that behaves on the distributed backend), not to "did the graph and the vector index disagree because they're really two databases." Happy to go deeper on the isolation model if you want to keep digging; the transactional core underneath is the part that makes all of it possible.
@ansari_adin The difference with SurrealDB is that all the data models, documents, graphs, vectors, time-series, run as native primitives inside a single Rust-based engine, not separate storage engines bolted together with a query layer on top. So when you're doing a cross-model operation, you're working within one transactional snapshot, not coordinating across subsystems. That's what makes the ACID guarantee real rather than approximate. 3.0 also overhauled concurrent writes on vector indexes specifically, and 3.1 added DiskANN as a second index type for larger-than-memory vector workloads if you want to dig into the details on either.
The tri-temporal model stands out. Most systems use a single timestamp and silently lose information they didn't know they'd need later. We've seen agents produce stale answers because correction propagation was eventually consistent rather than atomic. When two agents simultaneously try to supersede the same fact with conflicting data, does Spectron record that as an explicit conflict or does last write win?
SurrealDB
Really great question @anand_thakkar1! The short answer: explicit conflict, not last-write-wins.
When a new fact contradicts an existing one across provenance (say two agents writing from different source types), the reconciler doesn't pick a winner. It emits an explicit uncertainty record and keeps both facts valid until the conflict is resolved, rather than letting one quietly overwrite the other. Even in the simpler same-source case, a correction supersedes by bounding the old fact's validity in time rather than deleting it, and a low-confidence write is refused rather than allowed to clobber a high-confidence one. Nothing is lost, and the contradiction is visible instead of silent.
On the truly-simultaneous case specifically: every write is one ACID transaction on a single substrate, so there's no cross-store propagation lag of the kind that produces the stale answers you're describing. The conflict is recorded in the same place the facts live, not reconciled after the fact by a background job. Happy to go deeper on the isolation semantics if you want to get into the concurrent-writer edge cases!
Haven't actually gotten to try it yet since it's still early preview, but I already know the use case I want to throw at it. I run long Opus sessions, usually right up against the 1M context, and I almost always forget to compact them, so I either hit the wall or lose a pile of good context when the session ends. A memory layer that consolidates and carries the important stuff between conversations on its own is exactly the thing I keep wishing I had, because then forgetting to compact stops being a problem. The memory just persists.
The reflection and consolidation between conversations is what sells it for me. And as someone who already lives in SurrealDB, having it all on one substrate in a single transaction is a big bonus. Can't wait to get off the waitlist.
SurrealDB
Long-running agent sessions shouldn't depend on remembering to compact at the right moment. The important context should persist, consolidate, and carry forward naturally between conversations.
Really excited for you to try it Lay and looking forward to your feedback, especially since you're already using SurrealDB and a part of our Ambassador Programme.
SurrealDB
This use case is right in the bullseye, @cloaky233. The thing worth calling out: compaction on its own is lossy by nature; you're squashing a session into a summary and quietly throwing away the detail you didn't know you'd need later. Spectron does compact, summarise, and "dream" too, but the difference is we never discard the original; the important facts get promoted into durable, queryable memory, and the full data and context stay in the knowledge graph underneath. So nothing has to be "remembered to be saved," and three sessions later you can still pull the specific thing instead of whatever survived the summary.
And because you already live in SurrealDB, that memory is sitting right next to the rest of your data on one substrate. Genuinely can't wait to hear how it holds up against your Opus sessions; that's exactly the kind of workload we want pushing on it.
SurrealDB
Hi Product Hunt 👋
I am Tobie, co-founder of SurrealDB. We are launching Spectron - the memory layer for AI agents, built on SurrealDB (open source; graph, vector, document, and structured records in one ACID transaction).
Why we built it
Agents kept looking great in demos and failing in week three: colliding embeddings with the same label, corrections losing to the next high-scoring vector, cross-tenant bleed, confident answers with no lineage. Those are data-layer problems, not “retrieval only.” Spectron is the data-layer answer on the engine we already had.
What it is
One substrate holding two kinds of memory, told apart by provenance rather than by separate stores:
Authoritative knowledge - org documents, policies, and product data, with ingestion for PDFs, code, images, audio, and video.
Conversational memory - the transcript itself, plus identity, knowledge, context, instructions, and unknowns the agent flags but cannot answer yet.
How it behaves
Provenance on every fact, down to the byte span in the originating turn or document chunk.
Corrections kept across three clocks tracked separately: when the database wrote a fact, when we first believed it, and when it was true in the world - plus where it was captured, when location matters.
Multi-tenancy and territory scoped in the engine, not patched on at the API.
When sources disagree, the more authoritative one is favoured and the conflict is recorded as an explicit uncertainty, never silently overwritten.
Memory evolves between interactions: background passes link previously-unrelated facts and crystallise beliefs from what the substrate has accumulated.
What early access includes
REST API, SDKs for Python, TypeScript, Kotlin, and Swift, MCP server (remember, recall, context, reflect, forget, upload, inspect).
We are opening access in waves. We will email you the moment your invite is ready, with everything you need to start building.
For this community: what is the worst memory failure you have seen ship to production, and what did the team do about it? The answers I trust are usually the unglamorous ones.
@tobiemh Interesting positioning, especially with vectors, graphs, documents, and relations all living in the same engine. For teams building AI agents today, what's been the most common reason they've chosen SurrealDB over combining multiple specialized databases?
SurrealDB
Great question, @nicole_hynek; it's one we get a lot. 🙏
There are two reasons, and the second is the one that matters more.
The glue between specialised databases is where agent systems actually break. When your vectors live in one store, your graph in another, and your documents in a third, you become responsible for keeping them consistent: dual writes, sync jobs, reconciliation, "the embedding exists but the source row was deleted" bugs. That's not the interesting part of building an agent, but it's where most of the late-night incidents come from.
When vectors, full-text, graph, and time all live in one engine, you can query across all of them in a single question - and that's exactly what better memory requires. "Find chunks semantically close to X, that mention Y, that belong to entities related to Z, that were valid as of last March." You can't fake that by stitching four databases together after the fact; the moment you split it across systems you lose the ability to reason over all four dimensions at once.
That unified query surface is what platforms like Spectron are built on. Memory that understands meaning, relationships, language, and time together isn't a feature you bolt on; it falls out of having one substrate that can answer all four in the same breath.
@tobiemh That makes a lot of sense. The operational complexity of keeping multiple databases synchronized is easy to underestimate until you're dealing with consistency issues in production.
The ability to query meaning, relationships, documents, and time together from a single system feels especially valuable for agent memory and retrieval workflows. Really interesting approach and awesome work on this!
SurrealDB
@nicole_hynek "easy to underestimate until production" is the painful version. The sync tax never shows up in the demo; it shows up in production, six months in, when two stores disagree and something downstream trusted the wrong one. One system just never creates that failure mode. Thank you @nicole_hynek, really appreciate the thoughtful engagement 🚀 !
agents confidently answering with outdated info because a correction got lost somewhere in the memory layer is one of those problems you don't notice until it costs you. provenance on every fact so you can trace where an answer came from should be standard
SurrealDB
@tina_chhabra Exactly, memory without provenance is risky because the agent can be wrong with confidence. That’s why provenance is such a big part of Spectron. You need to know where a fact came from, when it changed, and whether it has been replaced. That is what makes agent memory usable in production.
SurrealDB
This is exactly the failure mode we built around, @tina_chhabra 🎉 !
The subtle part is that a correction getting "lost" is usually a deletion in disguise; most systems overwrite the old fact and hope the new one propagates everywhere it needs to. Spectron never deletes a superseded fact; it bounds when the old one was valid and makes the new one current, so the agent answers with today's truth but can still tell you what it believed last quarter and why it changed. Provenance on every fact, down to the source it came from, is what makes that traceable rather than a leap of faith.
Honestly, the whole design goal was to get as close to human memory as we could: memory that revises itself, holds onto its own history, and knows how it came to believe something. The twist is making that a collective memory, so a whole organisation or team shares one trusted recollection instead of every agent and person carrying their own slightly-wrong copy. That is when it stops being a database and starts feeling like the team actually remembers.
I've been watching and documenting Spectron for a good length of time now, and here are some of the most interesting parts I recommend keeping an eye on when first experimenting with it:
Tri-temporal model (i.e. three types of time): there is time in the sense of when something was valid in the real world (Austria-Hungary was valid from 1867 to 1918), there's time in the sense of when you learned something ("We learned about Austria-Hungary in 1994 in school"), and there's system time (when facts were registered)
Different types of knowledge: ranges from authoritative knowledge (facts you know are true and add as such) going down to more experiential and reflective knowledge, and finally to uncertainty so that an agent can actually say "I don't know" instead of trying its best to hack something together
Supersession: this is where something that used to be true no longer is, but it doesn't mean that the old fact gets deleted. (e.g. you get a new job and are now a pilot instead of a fire fighter) The old info is just valid until a certain date, and the new info becomes the new state.
And so on...it basically emulates memory the way we use it as humans.
SurrealDB
Spot on @mithridates, you've put your finger on exactly the part we obsessed over most. 🙌
The tri-temporal model is the thing people underestimate until they hit it in the wild: "when it was true," "when we found out," and "when the system recorded it" are three genuinely different questions, and almost every memory system collapses them into one timestamp and quietly loses information. Keeping them separate is what lets an agent reason about what it knew and when - not just what's true now.
And yeah, the supersession point is the heart of it: we never destroy the past, we just bound its validity. Your firefighter→pilot example is perfect; ask "what do they do?" and you get pilot; ask "what did they do in 2019?" and the old fact is still right there, intact.
The "I don't know" piece is the one I'd love more people to push on. Confidently-wrong agents are the real failure mode, so modelling uncertainty as a first-class citizen mattered more to us than squeezing out another point of benchmark accuracy.
The fun part is what these three unlock together: querying memory as of any point in the past, watching beliefs get revised over time, replaying how the agent's understanding evolved. That's where it starts feeling like actual memory.
How does provenance work in practice? If a fact originates from multiple sources and is later corrected, what does the audit trail and retrieval experience look like?
SurrealDB
Good question @jn263, this is one of the parts spent a considerable amount of time designing.
Provenance is a stored field, not a best-effort annotation. Every fact-bearing row carries where it came from, pinned down to the byte span in the originating turn or document chunk, plus a trust prior for that source. When multiple sources independently support the same fact, that isn't flattened into one record; each assertion stays its own row with its own provenance, and corroboration is tracked explicitly (proof counts, and promotion that points back at the originals). So "three sources said this" is something you can actually see and walk, not a single averaged-out fact.
When sources disagree, we deliberately don't silently pick a winner. A cross-provenance contradiction (say a conversation says one thing and a document says another) emits an explicit uncertainty row, and both facts stay valid until it's resolved, rather than one quietly overwriting the other. Same-source updates supersede normally, and even then nothing is deleted: the prior belief stays with its validity bounded in time, so the correction is a chain you can replay.
Underneath that, sit three clocks: when a fact was true in the world, when we first learned it, and when the system recorded it. So the audit trail answers "what did we believe, on what basis, and when did that change".
On retrieval: by default you get the current view with sources attached, traceable back to the bytes. But you can also ask "as of" a past point in time and get what the system would have answered then, with the provenance that applied at that moment. A correction shows up as a transition in the history, not a gap.