--- title: "Technical deep dive | SurrealDB" description: "Technical breakdown of SurrealDB's architecture, storage engine, query language, and use cases for modern apps and AI workloads." url: https://surrealdb.com/surrealdb/deep-dive --- TECHNICAL DEEP DIVE # What is SurrealDB? One database for every model your AI agents need - documents, graphs, vectors, time-series, geospatial, and relational, in a single ACID transaction. A deep dive into the architecture, storage engine, query language, and use cases that make SurrealDB a multi-model database built for modern applications and AI workloads. [Start free with SurrealDB](https://studio.surrealdb.com/current/instances/deploy) [Read the docs](https://surrealdb.com/docs/what-is-surrealdb) 1. ![Babcock](https://surrealdb.com/assets/static/babcock.lo4rnVg1.svg) 2. ![ING](https://surrealdb.com/assets/static/ing.X3I6S3_V.svg) 3. ![British Airways](https://surrealdb.com/assets/static/british-airways.KEsZiwV-.svg) 4. ![Nvidia](https://surrealdb.com/assets/static/nvidia.DaIEuMil.svg) 5. ![Apple](https://surrealdb.com/assets/static/apple.D5pq4flY.svg) 6. ![SpaceX](https://surrealdb.com/assets/static/spacex.CQJEk-IL.svg) 7. ![Samsung](https://surrealdb.com/assets/static/samsung.CH-vQgnb.svg) 8. ![adidas](https://surrealdb.com/assets/static/adidas.DdTC5qhk.svg) 9. ![Tencent](https://surrealdb.com/assets/static/tencent.paQmLxyy.svg) 10. ![Alibaba](https://surrealdb.com/assets/static/alibaba.B16idgfM.svg) 11. ![PolyAI](https://surrealdb.com/assets/static/poly-ai.c3w_fAg6.svg) 12. ![Later](https://surrealdb.com/assets/static/later.Ds736jFO.svg) 13. ![Verizon](https://surrealdb.com/assets/static/verizon.BI7CajdX.svg) 14. ![Liberty Mutual](https://surrealdb.com/assets/static/liberty-mutual.B7qOU1pd.svg) 15. ![Walmart](https://surrealdb.com/assets/static/walmart.BjDg_Sr8.svg) 16. ![Carrier](https://surrealdb.com/assets/static/carrier.D21gC6NX.svg) 17. ![Saks Fifth Avenue](https://surrealdb.com/assets/static/saks-fifth-avenue.COIDpLSb.svg) 18. ![San Francisco Compute Company](https://surrealdb.com/assets/static/sfcc.B7jlImq4.svg) 19. ![Shield AI](https://surrealdb.com/assets/static/shield-ai.pINZ0KJr.svg) 20. ![Wix](https://surrealdb.com/assets/static/wix.DvHhmoBi.svg) 01 | OVERVIEW ## The short version SurrealDB unifies documents, graphs, vectors, time-series, geospatial, and relational data in one engine - one query language (SurrealQL), one ACID transaction, one consistent snapshot. Agent Memory adds persistent, structured agent memory and the distributed storage layer adds object-storage-backed compute-storage separation - together forming a single vertical stack from object storage to agent memory, with no glue code. THE PROBLEM ## The fragmented data stack Building an enterprise AI agent today means stitching together five or six independent databases: a document store, a graph database, a vector index, a relational engine, a memory layer, and a message broker. Each has its own consistency model, its own query language, and its own failure modes. When agents fail, it is rarely because the model is weak. It is because the data layer underneath cannot deliver consistent, complete context in a single operation. THE SOLUTION ## One database, one transaction SurrealDB is the only data layer an enterprise agent needs. Your model, your data, one database. It provides documents, graphs, vectors, time-series, geospatial, and relational structures as native primitives within a single engine, coordinated by a single query language (SurrealQL), and governed by a single ACID transaction boundary. Combined with Agent Memory for persistent Agent Memory and distributed storage backed by object storage, it forms one vertical stack from object storage to agent memory. THE VERTICAL STACK ## From object storage to agent memory Agent Memory gives agents persistent memory. SurrealDB unifies every data model in one ACID transaction. The storage engine separates compute from storage on commodity object storage. No glue code. No middleware. Applications ![Agent Memory](https://surrealdb.com/assets/static/surrealdb-icon.C3ORaDk9.svg) Agent Memory Entity extraction Knowledge graph Temporal facts Hybrid retrieval ![SurrealDB](https://surrealdb.com/assets/static/surrealdb-icon.C3ORaDk9.svg) Database Documents Graphs Vectors Time-series Auth APIs Distributed write nodes Node A Node B Node C Object storage (S3 / S3-compatible) *The SurrealDB vertical stack: object storage, the multi-model engine, and Agent Memory in one path.* 02 | SURREALQL ## SurrealQL: one query, every model The best way to understand SurrealQL is to see the payoff first. Consider a retrieval query for an AI agent that needs to find relevant knowledge base articles for a customer: That single statement applies tenant isolation, temporal filtering, graph traversal through the customer's product relationships, and hybrid vector + full-text ranking. In a multi-system architecture, this would require four or five round-trips across independent databases with no transactional consistency between them. In SurrealQL, it is one query, one transaction, one consistent snapshot. ``` SELECT id, title, vector::distance::knn() AS vec_dist, search::score(1) AS ft_score, (1 - vector::distance::knn()) * 0.6 + search::score(1) * 0.4 AS blend_score FROM knowledge_base WHERE tenant = $tenant AND updated_at > time::now() - 30d AND id IN $customer->owns->product ->has_issue->knowledge_base AND content_embedding <|50,20|> $query_embedding AND content @1@ $query_text ORDER BY blend_score DESC LIMIT 10; ``` [Try SurrealQL in Studio](https://studio.surrealdb.com/) 03 | SCOPE-FIRST RETRIEVAL ## One query, one transaction This works because SurrealQL treats every data model - documents, graphs, vectors, full-text, time-series, geospatial, relational - as composable operators within the same syntax. Here is how each one works individually. Scope Narrow the candidate set Tenant isolation tenant = $tenant Temporal filter updated_at > 30d ago Graph traversal →owns→product→… Narrowed candidate set Rank Hybrid score ranking Vector similarity KNN · weight: 0.6 \+ Full-text search BM25 · weight: 0.4 *Scope-first retrieval: narrow by tenant, time, and graph scope before ranking candidates by hybrid score.* 04 | DATA MODELS ## Composable by design ### Graph relationships Graph edges are native to the data model. Relationships are created with `RELATE` and traversed with arrow syntax. What makes SurrealDB's graph model distinct is that every edge is a full document - it can carry its own fields, metadata, embeddings, timestamps, and permissions. ### Vector search Vector similarity search is built into the query engine. You define an index on a field and query it with distance functions. The structured filter (`category = 'tools'`) narrows the candidate set before the vector search runs - scope first, rank second. ``` RELATE customer:alice->purchased->product:widget_pro SET quantity = 2, date = time::now(), source = 'web', sentiment_embedding = $embedding;SELECT ->purchased[WHERE date > time::now() - 30d]->product.name FROM customer:alice; ``` ``` DEFINE INDEX product_embedding ON product FIELDS embedding HNSW DIMENSION 1536 DIST COSINE;SELECT id, name, vector::distance::knn() AS distance FROM product WHERE category = 'tools' AND embedding <|10,40|> $query_embedding ORDER BY distance; ``` ### Documents and record links SurrealDB stores data as schemaless or schemafull documents. Record links replace foreign key joins with direct references that the engine resolves at query time, eliminating N+1 query patterns. ``` CREATE order SET customer = customer:alice, items = [product:widget_pro, product:gadget_x], total = 79.98;-- Traverse record links inline, no JOIN neededSELECT customer.name, items.name, total FROM order; ``` TEMPORAL AND SEARCH ## Time-series, full-text, and real-time ### Time-series and temporal queries Native duration arithmetic, temporal aggregation functions, and point-in-time `VERSION` reads for time-travel queries without blocking writers. ### Full-text search BM25-scored full-text indexes with configurable analysers and the `@@` match operator. Composes with every other model in the same query. ``` -- Aggregate sensor readings by hourly windowsSELECT time::floor(recorded_at, 1h) AS hour, math::mean(value) AS avg_temp, math::max(value) AS peak FROM reading WHERE sensor = sensor:temp_01 AND recorded_at > time::now() - 7d GROUP BY hour ORDER BY hour DESC;-- Time-travel: query the exact state 5 days agoSELECT * FROM reading VERSION d'2026-03-20T00:00:00Z'; ``` ``` DEFINE ANALYZER english TOKENIZERS blank, class FILTERS lowercase, snowball(english);DEFINE INDEX ft_content ON article FIELDS content FULLTEXT ANALYZER english BM25;SELECT id, title, search::score(1) AS relevance FROM article WHERE content @1@ 'distributed consensus' ORDER BY relevance DESC; ``` ### Live queries, events, and more Geospatial queries work on native GeoJSON types with built-in distance, bearing, and containment functions. `LIVE SELECT` provides real-time subscriptions over WebSockets. `DEFINE EVENT` triggers server-side logic on data changes, and changefeeds provide ordered, durable mutation streams per table. Every one of these models composes with every other. A single SurrealQL statement can combine a graph traversal with a vector search, scope it by a full-text match, filter by a temporal range, restrict by geospatial proximity, aggregate relationally, and stream the results to a live subscriber. 05 | ARCHITECTURE ## ACID transactions across every model Every SurrealQL statement executes within an ACID transaction, regardless of which data models are involved. If a single query updates a document, creates a graph edge, writes a vector embedding, and persists an Agent Memory fact, either all of those operations commit or none do. Every agent follows the same cycle: read context, reason over it, write the result. In multi-system architectures, reads and writes span databases with independent consistency models, so by the time the agent writes back, the data it read may have already changed. SurrealDB executes the entire loop within a single ACID transaction. The context the agent reads is the same consistent snapshot it writes against. Single ACID transaction Read Docs + graphs Vectors + memory Consistent snapshot Think LLM reasoning Tool selection Model inference Write Update state Persist memory Atomic commit Next cycle ↓ *The read-think-write agent loop executing inside a single ACID transaction.* KV SUBSTRATE ## One engine, one key-value substrate At its lowest layer, SurrealDB stores all data - records, graph edges, index entries, metadata - as binary key-value pairs in a transactional KV store. The "models" are not separate engines. They are different query patterns and data structures layered on top of a single KV substrate. A document is a KV entry with a `*` path separator. A graph edge pointer uses a `~` tag with an empty value - the key itself encodes the relationship. Index data entries use a `+` prefix. Because every model shares the same sorted byte stream, there is no serialisation boundary between subsystems. When a query combines a graph traversal with a vector search, the query planner sees the entire operation and executes it against a single consistent snapshot. The KV store keeps keys in sorted binary order, so every "query by scope" becomes a tight prefix range scan. Graph traversals are not joins - they are prefix scans on contiguous slices of the sorted key space. When you write `user:tobie->contributes->repo` in SurrealQL, the engine jumps directly to the right byte range. A document lookup, a graph traversal, and an index scan all resolve to the same fundamental operation: scan a contiguous range of bytes. Key structure for user:tobie / root * sep 00 00 00 01 NamespaceId * sep 00 00 00 02 DatabaseId * sep user\0 table * type \x03tobie\0 record ID → {name: "Tobie"} Type tag determines the model * Document / relational record Value = full document body ~ Graph edge pointer Value = empty (key encodes the relationship) \+ Index data entries B-tree, HNSW vector, full-text (BM25) *Documents, graph edges, and index entries all compile to keys in one sorted key-value substrate.* 06 | QUERY ENGINE ## Specialised indexes, streaming execution While the storage is unified KV, the indexing layer is purpose-built for each model: HNSW graphs for vector similarity, BM25-scored inverted indexes for full-text, B-tree derivatives for structured lookups, and the directional key structure itself for graph traversals. SurrealDB 3.0 rearchitected the query engine around streaming execution, processing results without materialising full intermediate result sets - critical for graph traversals where intermediate sets can explode in size. ``` -- HNSW graph for vector similarityDEFINE INDEX product_vec ON product FIELDS embedding HNSW DIMENSION 1536 DIST COSINE;-- BM25 inverted index for full-textDEFINE INDEX article_ft ON article FIELDS content FULLTEXT ANALYZER english BM25;-- B-tree for structured lookupsDEFINE INDEX user_email ON user FIELDS email UNIQUE;-- Streaming execution: graph traversal-- feeds into vector ranking without-- materialising the intermediate setSELECT id, name, vector::distance::knn() AS dist FROM customer:acme->owns->product WHERE embedding <|10|> $query_vec ORDER BY dist LIMIT 5; ``` 07 | STORAGE ## Pluggable storage, unified interface The KV substrate is pluggable. SurrealKV is a custom-built embedded engine using a Versioned Adaptive Radix Trie (VART) over an LSM-tree architecture - it provides O(m) lookup matched to SurrealDB's hierarchical key layout, with built-in MVCC for time-travel `VERSION` queries. SurrealMX is in-memory with optional persistence via append-only logs and snapshots. The distributed storage layer is described below. Every backend exposes the same transactional interface - switch engines without changing a single query. ``` # SurrealKV - embedded, VART + LSM-tree, MVCCsurreal start surrealkv://production.db# SurrealMX - in-memory, optional persistencesurreal start memory# RocksDB - embedded, LSM-treesurreal start rocksdb://production.db# Same queries. Same transactions.# Every backend. ``` DISTRIBUTED STORAGE ## Compute-storage separation For production-scale distributed deployments, the distributed storage layer separates compute from storage entirely. Transactional data is durably persisted in commodity object storage - Amazon S3 or any S3-compatible store. Compute nodes are stateless and elastic. This layer, and the consensus and recovery behaviour described below, is an Enterprise Edition capability; the community edition runs the embedded backends above. Most distributed databases were designed around provisioned disks attached to compute nodes: scaling meant a bigger machine, and the storage tier was the machine. The generation that followed separated compute from storage but tied the storage layer to a proprietary cloud database service - Aurora, AlloyDB - solving the elasticity problem by coupling the data to a single vendor's platform. SurrealDB takes the third path. Transactional data is placed directly in commodity object storage and the database runs as stateless, elastic compute on top, with no proprietary storage tier in between. Data can live in any S3-compatible store - a major cloud, a private cloud, or an on-premise environment - and the compute layer is portable across all of them. Client Load balancer layer Request routed to SurrealDB write node, or SurrealDB read-proxy node Branch lines from load balancer to availability zones Availability Zone A Highly-scalable read compute SurrealDBread node SurrealDBread node SurrealDBread node SurrealDBwrite node Availability Zone B Highly-scalable read compute SurrealDBread node SurrealDBread node SurrealDBread node SurrealDBwrite node Availability Zone C Highly-scalable read compute SurrealDBread node SurrealDBread node SurrealDBread node SurrealDBwrite node Storage lines from availability zones to object storage ![Distributed storage](https://surrealdb.com/assets/static/surrealds-icon.C6Eh8iX9.svg) Object storage (S3 / S3-compatible / durable cold tier) *The distributed storage layer separates stateless, elastic compute from durable object storage.* INDEPENDENT SCALING Compute and storage scale separately. Add read replicas without adding storage, or grow datasets without adding compute. SCALE TO ZERO Compute nodes shut down when idle. Data remains safe in object storage. Recovery time is proportional to log delta, not dataset size. BUILT-IN DURABILITY S3-class storage offers 99.999999999% durability. No separate backup infrastructure or snapshot management needed. INSTANT BRANCHING Create petabyte-scale database branches in seconds via logical metadata references - Git-like workflows for data. STORAGE ECONOMICS Object storage costs a fraction of provisioned disk, and the total dataset can far exceed the local capacity of any running instance. CROSS-ZONE REPLICATION Data flows through shared object storage rather than streaming between nodes, structurally reducing the cross-availability-zone traffic that dominates the network bill of a traditional distributed cluster. QUORUM CONSENSUS ## No single leader, no split brain Distributed transactions are coordinated by quorum rather than by an elected leader. Each availability zone runs its own write node, so write throughput scales horizontally instead of funnelling through a single primary. A transaction commits once a quorum of zones acknowledges it. This removes the leader as both a bottleneck and a failure mode, and avoids the additional round-trip that leader-based replication pays on every write - consensus happens at the writing node itself. 1 transaction → 1 quorum decision Every transaction is encapsulated within a quorum consensus decision. Transaction consensus is performed at the writing node, allowing writes to horizontally scale across all write nodes in a cluster. Quorum transaction (majority commit) Quorum consensus Storage engine data storage Storage engine data storage Storage engine data storage *Each availability zone runs its own write node; transactions commit on quorum acknowledgement.* RESILIENCE ## Node failure and recovery When a compute node fails there is no state to rebuild from its peers. A replacement node restores from object storage and replays the transaction log from the last durable point. Recovery time is therefore a function of the log delta since that point, not of the size of the dataset - a hundred-gigabyte database and a hundred-terabyte database recover in the same time from the same log position. Client Load balancer layer Request routed to SurrealDB write node, or SurrealDB read-proxy node Branch lines from load balancer to availability zones Availability Zone A Write queries are handled by write nodes SurrealDBread proxy node SurrealDBwrite node Availability Zone B Node B acknowledges writes. Persistence succeeds, quorum fulfilled. SurrealDBwrite node Availability Zone C Node C fails to acknowledge writes. Persistence fails, but quorum fulfilled. SurrealDBwrite node LSM tree layers are retrieved from object storage so the query requests ranges which are not in the local storage cache LSM tree layers are synced to object storage after range compaction Transaction log written asynchronously to object storage After the transaction log syncs from object storage, the node syncs the latest writes from a SurrealDB write node, and forms part of the quorum On node recovery, data is restored from object storage, and the transaction log on object storage is tailed for the latest writes Storage lines from zones to object storage ![Distributed storage](https://surrealdb.com/assets/static/surrealds-icon.C6Eh8iX9.svg) Object storage (S3 / S3-compatible / durable cold tier) ### Behaviour: **Quorum commit:** transaction is committed once a quorum acknowledges the writes. **Durable log:** committed writes are safe via a replicated write-ahead-log, with asynchronous durability to object storage for fast node recovery and secondary-region disaster recovery. **Catch-up:** failed node restarts and replays transaction log from object storage (for reduced cost) and from cross-availability zone (for recent transactions). **Node crash:** a new node catches up with the cluster, regardless of the existing local state, using transaction-log replay before joining the quorum. ### Outcome: Transaction commit succeeds with quorum majority Client receives transaction success confirmation SurrealDB write node in Availability Zone C catches up with cluster after restart No split-brain / consistent ordering Significant reduction in cross-availability zone traffic *A replacement node restores from object storage and replays the transaction log.* 08 | AGENT MEMORY ## Persistent agent memory Most memory solutions for AI agents are middleware layers that sit above a fragmented data stack. They abstract over the seams between your vector database, your document store, and your graph engine - but the seams are still there. Memory writes go to one system, application data to another, and there is no transactional guarantee that the two are consistent. When an agent retrieves a memory that references data which has since changed, it reasons over a stale view of the world. Agent Memory eliminates this. It is a persistent, structured memory engine built on SurrealDB. When a conversation is ingested, Agent Memory autonomously extracts entities, builds knowledge graph connections, tracks temporal facts with tri-temporal validity, and indexes everything for hybrid retrieval. Because memory and application data share one substrate, each write lands in the same transactional store the rest of your data lives in - no second system to keep in step, and no cross-database consistency gap. Episodic The raw conversational record - sessions and turns as authored, in order. The source of truth every extracted category cites back to. Identity Durable facts about who the principal is: name, role, employer, long-lived attributes. Long retention, low decay. Knowledge What the principal has learnt or shared - project facts, observations, references. Decays without reinforcement. Context What is happening right now: active topics, recent intents, the working set for the current conversation. Replaced rapidly. Instructions Behavioural rather than factual memory - how the principal wants to be served. Applied at prompt-assembly time, not at retrieval. Uncertainty Explicit "not known yet" rows, raised when confidence falls below the floor or provenance conflicts. Gaps stay visible instead of being papered over. Because Agent Memory runs on SurrealDB, it composes naturally with every other data model. A single SurrealQL statement can traverse a user's purchase history through graph edges, filter reviewed products by semantic similarity, and retrieve only currently valid preferences via temporal constraints - all in one query, one transaction. Multiple agents can read and write to the same memory surface with full ACID guarantees - coordination happens through shared context rather than message passing. Agent Memory inherits the full security model (row-level permissions, namespace isolation) and the full storage stack (distributed storage, scale-to-zero, branching). Between conversations, it continues working in the background: discovering connections, consolidating knowledge, resolving ambiguities, and inferring implicit relationships. ``` LET $user = user:jaime;LET $query_vec = fn::embed( "What products does this user like?");SELECT ->purchased->product AS purchase_history, ->reviewed->product[ WHERE vector::similarity::cosine( embedding, $query_vec ) > 0.8 ] AS relevant_products, ->preferences[ WHERE valid_at <= time::now() ] AS current_preferences FROM ONLY $user; ``` 09 | CAPABILITIES ## Beyond the core models ### Geospatial queries Native GeoJSON support with built-in distance, bearing, area, and containment functions. No PostGIS extension. Geospatial composes with everything else - find stores within 5km and traverse their inventory graph in one statement. ``` SELECT name, geo::distance(location, $user_location) AS dist, ->stocks->product[ WHERE category = 'electronics' ] AS inventory FROM store WHERE geo::distance( location, $user_location ) < 5000 ORDER BY dist; ``` ### Plugins: the extension system A WebAssembly-based extension system. Write an extension in Rust, compile it to a `.surli` module, load it into a running database. Your functions become callable from SurrealQL, sandboxed in WASM, participating in ACID transactions. See [surrealdb.com/surrealdb/extensions](https://surrealdb.com/surrealdb/extensions). ``` DEFINE MODULE mod::sentiment FROM f"modules:/sentiment.surli" UNSIGNED;UPDATE article SET sentiment = mod::sentiment::analyze( content ), keywords = mod::sentiment::extract( content )WHERE created_at > time::now() - 1h; ``` ### DEFINE API: custom endpoints in the database `DEFINE API` creates custom HTTP endpoints directly inside SurrealDB - no external framework, no routing layer. The endpoint inherits ACID transactions, row-level permissions, and multi-model query capabilities. For agent-facing APIs and internal tools, this eliminates the entire API routing layer. ``` DEFINE API "/agent/context" FOR post PERMISSIONS WHERE $auth.role = "agent" THEN { LET $results = SELECT * FROM knowledge WHERE vector::similarity::cosine( embedding, $request.body.embedding ) > 0.8; RETURN { status: 200, body: $results, } }; ``` ### Single binary, runs everywhere SurrealDB compiles to a single binary. It runs in the browser via WebAssembly, embedded in edge devices, as a serverless function, as a single-node server, or as a distributed cluster on object storage. The query engine, data model, and application code are identical across all environments - a prototype built embedded in a browser can move to a distributed cluster in production without rewriting a single query. 10 | COMPARISON ## How SurrealDB compares *How SurrealDB compares to single-purpose databases. Reflects publicly documented capabilities as of June 2026.* | Feature | Postgres | Neo4j | Pinecone / Weaviate | SurrealDB | | --- | --- | --- | --- | --- | | Data models | Relational + extensions | Graph + native vector index | Vector-first | Documents, graphs, vectors, time-series, geospatial, relational | | Graph support | Recursive CTEs | Native (Cypher) | None | Native (arrow syntax, edges as documents) | | Vector search | pgvector extension | Native vector index | Native ANN (specialised) | Native, composable with filters + graphs | | Transactions | ACID, single model | ACID, graph | Tunable / eventual | ACID across every model | | Agent Memory | External middleware | External middleware | External middleware | Agent Memory (built on SurrealDB, ACID-consistent) | | Storage | Coupled compute + storage | Coupled, cache-dependent | Managed service | Object-storage-backed, compute-storage separation | | Extensibility | C extensions, PL/pgSQL | Java / APOC plugins | Limited | WebAssembly extensions (sandboxed) | 11 | SUMMARY ## The full picture The distributed storage layer is backed by S3-class object storage with quorum consensus, compute-storage separation, and scale-to-zero. SurrealDB provides the unified data layer: documents, graphs, vectors, time-series, geospatial, and relational structures as native primitives in one ACID transaction. Agent Memory provides persistent, structured agent memory that commits atomically alongside application data. 12 | FREQUENTLY ASKED QUESTIONS ## Frequently asked questions If SurrealDB does everything, doesn't that mean it's bad at everything? Why would I use SurrealDB over Postgres? Is SurrealDB a fork or wrapper? Why Rust? Is SurrealDB production-ready? What is quorum consensus? Which object storage providers are supported? How does scale-to-zero work? How does instant branching work? GET STARTED ## Start building with SurrealDB Object storage to agent memory. A single stack, a single transaction, one query language. ![Samsung](https://surrealdb.com/assets/static/4c58b81e7b3c9466.C_Hv0eml.svg)![NVIDIA](https://surrealdb.com/assets/static/nvidia.DaIEuMil.svg)![Apple](https://surrealdb.com/assets/static/f7dc2519e0d212bc.Cn8MYAK7.svg)![Verizon](https://surrealdb.com/assets/static/18b99996c689000f.B5PQ-nI9.svg)![Tencent](https://surrealdb.com/assets/static/401d8346058682c8.DqM87mst.svg) SOC 2 Type 2 GDPR Cyber Essentials Plus ISO 27001 [Start free with SurrealDB](https://studio.surrealdb.com/current/instances/deploy) [Talk to our team](https://surrealdb.com/contact/sales) ```json {"@context":"https://schema.org","@type":"Organization","name":"SurrealDB","url":"https://surrealdb.com","logo":"https://surrealdb.com/assets/static/logo.BG7_TG2b.svg","description":"SurrealDB is the unified data layer for AI. A multi-model database for documents, graphs, vectors, and time-series.","foundingDate":"2022","legalName":"SurrealDB Ltd","identifier":{"@type":"PropertyValue","propertyID":"GB-COH","value":"13615201"},"address":{"@type":"PostalAddress","streetAddress":"3rd Floor, 1 Ashley Road","addressLocality":"Altrincham","addressRegion":"Cheshire","postalCode":"WA14 2DT","addressCountry":"GB"},"contactPoint":[{"@type":"ContactPoint","contactType":"customer support","email":"support@surrealdb.com","url":"https://surrealdb.com/contact","availableLanguage":"English"},{"@type":"ContactPoint","contactType":"sales","email":"info@surrealdb.com","url":"https://surrealdb.com/contact","availableLanguage":"English"},{"@type":"ContactPoint","contactType":"security","email":"security@surrealdb.com","url":"https://surrealdb.com/.well-known/security.txt","availableLanguage":"English"},{"@type":"ContactPoint","contactType":"legal","email":"legal@surrealdb.com","url":"https://surrealdb.com/legal","availableLanguage":"English"}],"hasCertification":[{"@type":"Certification","name":"SOC 2 Type 2"},{"@type":"Certification","name":"GDPR"},{"@type":"Certification","name":"Cyber Essentials Plus"},{"@type":"Certification","name":"ISO 27001"}],"owns":[{"@type":"SoftwareApplication","name":"SurrealDB","url":"https://surrealdb.com/surrealdb"},{"@type":"SoftwareApplication","name":"Agent Memory","url":"https://surrealdb.com/agent-memory"}],"knowsAbout":["multi-model databases","document databases","graph databases","vector search","time-series databases","SurrealQL","Agent Memory","real-time databases","embedded databases","context layer","graph ontology","distributed database","knowledge graphs","distributed transaction protocols","highly-scalable databases"],"sameAs":["https://www.wikidata.org/wiki/Q124316308","https://github.com/surrealdb/surrealdb","https://twitter.com/surrealdb","https://www.youtube.com/@surrealdb","https://www.linkedin.com/company/surrealdb","https://discord.gg/surrealdb","https://www.reddit.com/r/surrealdb","https://www.instagram.com/surrealdb","https://medium.com/surrealdb","https://dev.to/surrealdb"]} ``` ```json {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://surrealdb.com"},{"@type":"ListItem","position":2,"name":"SurrealDB","item":"https://surrealdb.com/surrealdb"},{"@type":"ListItem","position":3,"name":"Deep dive","item":"https://surrealdb.com/surrealdb/deep-dive"}]} ``` ```json {"@context":"https://schema.org","@type":"TechArticle","headline":"What is SurrealDB? An engineering deep dive","description":"Technical breakdown of SurrealDB's architecture, storage engine, query language, and use cases for modern apps and AI workloads.","about":"SurrealDB architecture, storage engine, and SurrealQL","mainEntityOfPage":"https://surrealdb.com/surrealdb/deep-dive","author":{"@type":"Organization","name":"SurrealDB","url":"https://surrealdb.com"},"publisher":{"@type":"Organization","name":"SurrealDB","url":"https://surrealdb.com"}} ``` ```json {"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","name":"If SurrealDB does everything, doesn't that mean it's bad at everything?","acceptedAnswer":{"@type":"Answer","text":"Fair instinct, but architecturally wrong here. SurrealDB is not a wrapper over separate engines - it is one engine where every model shares a single KV substrate, a single query planner, and a single transaction coordinator. There are no seams between subsystems, no serialisation boundaries, no index coordination overhead. The cost of adding a graph traversal to a vector query is additive, not multiplicative. A purpose-built, single-model database will beat SurrealDB at its own specialty in isolation. But in production, your agent doesn't need \"just vector search.\" It needs vector search scoped by a graph traversal, filtered by tenant and time, ranked by a hybrid score, and committed atomically alongside a memory update. The specialised system is fast at step one - the other four steps require separate systems, network round-trips, and glue code that add more latency and failure modes than the per-model difference saves."}},{"@type":"Question","name":"Why would I use SurrealDB over Postgres?","acceptedAnswer":{"@type":"Answer","text":"If your workload is purely relational, Postgres is excellent. The question gets interesting when you start adding pgvector for embeddings, recursive CTEs for graph traversal, Elasticsearch for full-text, Redis for real-time subscriptions, and a separate auth service - each with its own consistency model and failure modes. SurrealDB collapses that into one engine. The same query that would require four round-trips across independent systems is a single SurrealQL statement in a single ACID transaction. There are structural differences too: record links replace foreign key joins, graph edges are full documents, row-level permissions and live queries are built in, and the distributed storage layer scales compute and storage independently on object storage - a cost model coupled architectures cannot match."}},{"@type":"Question","name":"Is SurrealDB a fork or wrapper?","acceptedAnswer":{"@type":"Answer","text":"Neither. SurrealDB is built from scratch in Rust - the query engine, storage engines, transaction coordinator, permission system, and real-time subscription layer were all designed and implemented from the ground up. When you run a query combining graph traversal with vector similarity and structured filters, it executes natively inside SurrealDB's own query planner. There is no Postgres underneath, no Neo4j, no Pinecone."}},{"@type":"Question","name":"Why Rust?","acceptedAnswer":{"@type":"Answer","text":"A database engine needs deterministic memory management, predictable latency, and safe concurrency. Rust's ownership model delivers all three without a garbage collector - no GC pauses during query execution, no unpredictable latency spikes under load, no memory overhead from a managed runtime."}},{"@type":"Question","name":"Is SurrealDB production-ready?","acceptedAnswer":{"@type":"Answer","text":"SurrealDB is generally available - the 3.x line is shipping patch releases, currently 3.2.4 - and is used in production by organisations including Nvidia, Samsung, Tencent, Verizon, Walmart, and ING across finance, healthcare, gaming, and defence. SurrealDB Cloud provides fully managed deployment with enterprise support, SLAs, and SOC 2 / ISO 27001 compliance."}},{"@type":"Question","name":"What is quorum consensus?","acceptedAnswer":{"@type":"Answer","text":"Quorum consensus coordinates distributed transactions without a single leader. Each availability zone has its own write node, and transactions commit once a quorum of zones acknowledges. This eliminates the single-leader bottleneck and provides lower latency than traditional Raft or Paxos-based systems."}},{"@type":"Question","name":"Which object storage providers are supported?","acceptedAnswer":{"@type":"Answer","text":"The distributed storage layer targets Amazon S3 and any S3-compatible object store - the endpoint is configurable, so self-hosted and third-party S3-compatible providers work too. Data lives in commodity object storage, which keeps it portable rather than coupled to a proprietary database storage tier."}},{"@type":"Question","name":"How does scale-to-zero work?","acceptedAnswer":{"@type":"Answer","text":"Because compute is separated from storage, the database engine is stateless. When no queries are running, compute instances can shut down entirely - data persists in object storage. When demand returns, new compute nodes restore state from object storage and replay the recent transaction log to rejoin the cluster. Cold-start time depends on the size of the transaction log delta, not the size of the dataset, so you only pay for the compute you use."}},{"@type":"Question","name":"How does instant branching work?","acceptedAnswer":{"@type":"Answer","text":"A petabyte-scale dataset can be cloned in seconds by creating a logical branch that shares the underlying object storage data. Changes on the branch are isolated, which enables Git-like workflows for databases - branch for testing, experiment freely, then merge or discard."}}]} ```