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.
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.
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.
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.
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
Spectron is our memory and knowledge layer for AI agents, built on top of SurrealDB. The idea is to give agents reliable, shared memory that can work across your stack, tools, and applications, rather than having context scattered across separate systems.
It comes with integrations and SDKs for TypeScript, JavaScript, Python, Swift, Kotlin, LangChain, LangGraph, n8n, and a growing set of MCP server integrations that work with tools like Claude, Codex, Cursor, and more out of the box.
What makes Spectron especially powerful is its focus on authoritative knowledge. It is designed to help agents understand what they know, where that knowledge came from, how it has changed over time, and whether an answer is grounded in the underlying data.
So whether you are building internal agents, customer-facing AI apps, or developer tooling, Spectron gives you a trusted memory layer that can grow with your ecosystem.
SurrealDB
Well put, @at_chiru 🙌
The line I'd underline for anyone skimming is "whether an answer is grounded in the underlying data". That's the part most memory layers quietly skip; they'll happily hand an agent a fact with no notion of where it came from or how confident to be in it.
Spectron treats provenance and grounding as first-class: every fact carries its source down to the byte span it came from, knows when it was true and when we learned it, and is honest when the answer is uncertain rather than confidently wrong. For anything customer-facing or high-stakes, that difference between "the model said so" and "here is the data this is grounded in, and here is how sure we are" is the whole ballgame.
A trusted memory layer that grows with your ecosystem is exactly the right way to put it; trust is the feature, and everything else is in service of it 🎉.