Building retrieval-augmented generation (RAG) systems for AI agents often involves using multiple layers and technologies to process structured data, vectors, and graph information. In recent months it has also become clear that agentic AI systems require memory, sometimes called episodic memory, to operate effectively.
The complexity and synchronization of different data layers to enable context can lead to performance and accuracy issues. This is a challenge that SurrealDB seeks to solve.
SurrealDB launched version 3.0 of its namesake database on Tuesday with a $23 million Series A extension, bringing total funding to $44 million. The company had adopted a different architectural approach compared to relational databases like PostgreSQL, native vector databases like Pinecone, or graph databases like Neo4j. The OpenAI engineering team recently detailed how it scaled Postgres to 800 million users using read replicas – an approach that works for read-heavy workloads. SurrealDB takes a different approach: store agent memory, business logic, and multi-modal data directly inside the database. Instead of synchronizing across multiple systems, vector searches, graph traversal, and relational queries all run transactionally in a single Rust-native engine that maintains consistency.
"People are running DuckDB, Postgres, Snowflake, Neo4J, Quadrant or Pinecone all at once, and then they’re wondering why they can’t get good accuracy in their agents," CEO and co-founder Toby Morgan Hitchcock told VentureBeat. "This is because they have to send five different queries to five different databases that contain only the knowledge or context that they deal with."
The architecture has resonated with developers, with 2.3 million downloads and 31,000 GitHub stars for the database to date. According to Hitchcock, current deployments span cutting-edge devices in cars and defense systems, product recommendation engines for major New York retailers, and Android ad serving technologies.
Agentic AI memory baked into the database
SurrealDB stores agent memory in the form of graph relationships and semantic metadata directly in the database, not in application code or external caching layers.
The Surrealism plugin in SurrealDB 3.0 lets system developers define how agents create and query this memory; The logic runs inside the database with transactional guarantees instead of middleware.
In practice this means: when an agent interacts with data, it builds context graphs that connect entities, decisions, and domain knowledge in the form of database records. These relationships are queryable through the same SurrealQL interface used for vector search and structured data. An agent asking about a customer issue can trace graph connections to related past events, pull vector embeddings of similar cases, and join with structured customer data – all in one transactional query.
"People no longer want to store only the latest data," Hitchcock said. "They want to store all that data. They want to analyze and have AI understand and drive all the data in an organization over the last year or two, because that informs their models, their AI agents about the context, the history, and therefore can deliver better results."
How does SurrealDB’s architecture differ from the traditional RAG stack
Traditional RAG systems query the database based on data types. Developers write separate queries for vector similarity search, graph traversal, and relational joins, then merge the results into application code. This creates synchronization delays as queries round-trip between systems.
In contrast, Hitchcock pointed out that SurrealDB stores data as binary-encoded documents, with graph relations embedded directly within them. Through SurrealQL a single query can traverse graph relations, perform vector similarity searches, and join structured records without leaving the database.
Hitchcock said this architecture also affects how consistency works at scale: Every node maintains transactional consistency even at 50+ node scale. When an agent writes a new context on node A, a query on node B immediately sees that update. No caching, no read replicas.
"A lot of our use cases, a lot of our deployments are where data is constantly updated and the relationships, context, semantic understanding, or graph connections between that data need to be constantly refreshed," He said. "So no caching. There are no read replicas. In SurrealDB, everything is transactional."
What does this mean for enterprise IT
"It’s important to say that SurrealDB is not the best database for every task. I’d love to say we are, but we’re not. And you can’t be," Hitchcock said. "If you only need analytics on petabytes of data and you’re never actually updating that data, you’re best off choosing object storage or columnar databases. If you are only dealing with vector search, you can go with a vector database like Quadrant or Pinecone, and that will suffice."
The inflection point comes when you need multiple data types at once. The practical benefits are visible in the development timeline. Hitchcock said that with multi-database orchestration, what used to take months to build can now launch in a matter of days.
<a href