Skip to content
STACK IT FAST

SurrealDB

Curated OSSClassicMulti-Model Real-Time Database20+ People

Audited from github.com/surrealdb/surrealdb

Multi-model document and graph database written in Rust with pluggable storage engines, live queries, and native vector search.

Language
Rust
Database
RocksDB
Hosting
Docker
Running for
3 years
Team
20+ People

Why this architecture

SurrealDB puts document, graph, relational and vector models behind one SurrealQL engine in a single Rust binary that runs embedded, in the browser via WebAssembly, or as a server over pluggable storage (RocksDB, SurrealKV, TiKV), with WebSocket live queries and row-level permissions built into the core.

Tech stack by layer

6 technologies · audited Sep 17, 2026
Backend & APIs
  • RustCore database engine, query parser, execution planner, and network server
  • TokioAsynchronous runtime handling concurrent network IO and storage operations
  • WebAssemblyPlugin execution sandbox using Wasmtime and WIT bindings
Data & Persistence
  • RocksDBEmbedded persistent key-value storage engine implementation
Infrastructure & Deploy
  • DockerMulti-stage container packaging for dev and minimal production images
  • OpenTelemetryDistributed tracing, metric collection, and OTLP export pipeline

SurrealDB architecture diagram

Open SVG
SurrealDB architecture diagramClients → SurrealDB server (SurrealQL); AI clients → SurrealDB server (MCP); SurrealDB server → Query engine (queries); Query engine → KV layer (read / write); Query engine → Vector indexes (vector search); Query engine → Surrealism (functions); SurrealDB server → OpenTelemetry (traces · metrics)CLIENTSSERVICESWORKERS & JOBSDATA & STORAGEEXTERNALClientsSDKs · SurrealQLAI clientsMCPSurrealDB serverRust · TokioQuery engineparser · plannerSurrealismWebAssembly · WasmtimeKV layerSurrealKV · RocksDB · TiKVVector indexesHNSW · DiskANNOpenTelemetryOTLP exportfunctionsSurrealQLMCPqueriesread / writevector searchtraces · metrics
How the main components of SurrealDB connect, drawn from the audited repository.
Diagram as text
  • Clients (SDKs · SurrealQL) → SurrealDB server (Rust · Tokio): SurrealQL
  • AI clients (MCP) → SurrealDB server (Rust · Tokio): MCP
  • SurrealDB server (Rust · Tokio) → Query engine (parser · planner): queries
  • Query engine (parser · planner) → KV layer (SurrealKV · RocksDB · TiKV): read / write
  • Query engine (parser · planner) → Vector indexes (HNSW · DiskANN): vector search
  • Query engine (parser · planner) → Surrealism (WebAssembly · Wasmtime): functions
  • SurrealDB server (Rust · Tokio) → OpenTelemetry (OTLP export): traces · metrics

Key architectural decisions

4 decisions
  1. 01

    Modular Key-Value Abstraction Layer

    Decouples the document-graph query engine from storage backends, supporting SurrealKV, RocksDB, and TiKV through unified traits.

  2. 02

    WebAssembly Extensibility Engine via Surrealism

    Uses Wasmtime and component models to execute sandboxed user-defined functions safely within query transactions.

  3. 03

    Built-in Model Context Protocol Server

    Native rmcp implementation enables direct AI agent querying and structured schema discovery without external middleware.

  4. 04

    Vector Search with Native DiskANN and HNSW

    Integrates high-performance vector indexing directly into the storage core for native retrieval-augmented generation.

How SurrealDB is built

How SurrealDB is structured

SurrealDB is organized as a Cargo workspace with dedicated crates separating query parsing, abstract syntax representations, the core transaction pipeline, network protocols, and runtime extensions. The root package delegates execution to surrealdb/core, which acts as the central execution engine responsible for document validation, relational graph traversals, and permissions enforcement. Query parsing is handled in surrealdb/parser and surrealdb/ast, turning SurrealQL statements into optimized execution plans.

The networking layer is isolated in surrealdb/server, which mounts Axum and Hyper HTTP/WebSocket endpoints alongside an embedded Model Context Protocol (MCP) server defined in surrealdb/mcp. Pluggable machine learning inferencing lives in surrealml, while surrealism provides a WebAssembly runtime sandbox using Wasmtime and WIT interfaces for secure extensibility.

Frontend

SurrealDB itself is an infrastructure database engine without an integrated web dashboard in this repository; client interactions occur through HTTP REST endpoints, WebSocket JSON-RPC channels, or the interactive command-line interface provided by surrealdb/server using Rustyline. Developers interact with database namespaces and tables through official SDKs or external web management tools like Surrealist.

Backend & APIs

The backend server is implemented using Axum and Tokio in surrealdb/server. It supports multiple communication paradigms:

  • HTTP/REST Endpoints: Allow standard stateless JSON document queries, batch execution, authentication, and health checking (/isready).
  • WebSocket Protocol: Powers persistent bidirectional sessions for high-frequency transactions and realtime query subscriptions.
  • GraphQL & GQL: Built-in support for GraphQL schemas using async-graphql alongside emerging ISO/IEC 39075 Graph Query Language standards.
  • MCP Server: Implements the Model Context Protocol using rmcp to expose database resources, tools, and execution contexts directly to AI coding assistants.

Authentication and permissions are enforced natively at the table and record level using custom SurrealQL access rules with Argon2, Scrypt, or JSON Web Tokens.

Data & persistence

SurrealDB decouples query execution from physical byte storage through an abstract key-value engine interface in surrealdb-core. This architecture allows SurrealDB to operate across various persistence backends:

  • In-Memory: Utilizing surrealmx for fast transient testing and embedded unit fixtures.
  • Embedded Single-Node: Using native surrealkv or RocksDB (surrealdb-rocksdb with snappy/lz4 compression) for durable local file persistence.
  • Distributed Clustered: Connecting to TiKV via surrealdb-tikv-client for horizontal scale-out and linear consistency across multiple server nodes.
  • Vector Indexing: Integrated DiskANN and HNSW vector index algorithms for high-dimensional semantic search and similarity retrieval.

Realtime / collaboration

Realtime data distribution is a core architectural primitive in SurrealDB. Clients can issue LIVE SELECT queries over WebSocket connections. When records are mutated, the transaction commit pipeline evaluates change streams against registered filter conditions and broadcasts delta payloads directly to subscribed client sessions.

Build, test & deploy

The build process is managed with Cargo and cargo-make using Makefile.toml and Makefile. Testing includes extensive integration suites in tests/, language grammar tests in language-tests/, fuzz testing with libfuzzer-sys in fuzz/, and continuous benchmarking in surrealdb/benches/ via Criterion. GitHub Actions workflows automate downstream SDK compatibility tests, Scorecard audits, and multi-architecture container publishing. Production Docker images are built in docker/Dockerfile using Chainguard base images for minimal attack surfaces.

Self-hosting notes

SurrealDB deploys as a standalone static binary or lightweight OCI container:

  • Single-node instances can be launched with surreal start --bind 0.0.0.0:8000 rocksdb:/data/surreal.db.
  • Distributed production clusters typically pair multiple stateless SurrealDB server nodes with a managed TiKV cluster using surreal start tikv://tikv-pd:2379.
  • OpenTelemetry metrics and traces can be routed to OTLP collectors by setting standard OTEL_EXPORTER_OTLP_ENDPOINT environment variables.

What to copy (and what not to)

What to copy:

  • The clean separation between the AST/parser crates and the core execution engine, allowing independent grammar evolution and parser fuzzing.
  • The storage engine trait abstraction that allows swapping between in-memory, local embedded LSM, and distributed key-value engines without touching query logic.
  • The implementation of the Model Context Protocol server directly inside the engine binary.

What not to copy:

  • The complex multi-engine build matrix with custom C++ bindings (such as RocksDB and TiKV client shims), which introduces significant compilation overhead and cross-platform packaging friction for small applications.

Sources & repo audit

Audited
Sep 17, 2026
Commit
18971ff
License
NOASSERTION

Independent analysis of repository at github.com/surrealdb/surrealdb. Spotted an inaccuracy? Use the claim form to request a correction.

Show this stack on your README or website
Tech stack of SurrealDB
[![Tech stack of SurrealDB on STACK IT FAST](https://stackitfast.com/badge/surrealdb.svg)](https://stackitfast.com/project/surrealdb)

Paste it into your README. It shows your current stack and links to this page.

Use this stack

Scaffold it with your agent

Paste this prompt into Claude Code, Cursor, Windsurf or AGY to start a project with SurrealDB's architecture.

  1. 1Copy the promptThe full markdown spec, with every layer and decision.
  2. 2Open your AI toolClaude Code, Cursor, Windsurf or Copilot, in a new repo.
  3. 3Paste and scaffoldUse it as the first instruction; review before you ship.
use-this-stack.md · 57 lines · 5.3 KB
# MISSION: Scaffold "SurrealDB" Production Architecture
You are an expert Senior Staff Software Architect and Full-Stack Engineer. Your mission is to scaffold and implement a production-grade, highly reliable, and modular codebase following the proven architecture of **SurrealDB**.
---
## 1. PROJECT SPECIFICATIONS & BENCHMARK
- **Reference Architecture**: SurrealDB
- **What It Does**: Multi-model document and graph database written in Rust with pluggable storage engines, live queries, and native vector search.
- **Domain & Category**: Multi-Model Real-Time Database
- **Production Scale**: 20+ People
- **Development Mode**: CLASSIC
- **Architectural Rationale**: SurrealDB puts document, graph, relational and vector models behind one SurrealQL engine in a single Rust binary that runs embedded, in the browser via WebAssembly, or as a server over pluggable storage (RocksDB, SurrealKV, TiKV), with WebSocket live queries and row-level permissions built into the core.
- **Live Website Reference**: https://surrealdb.com
- **Source Repository**: https://github.com/surrealdb/surrealdb
---
## 2. PRODUCTION TECH STACK
- **Full Stack Array**: Rust, RocksDB, WebAssembly, Tokio, Docker, OpenTelemetry
- **Primary Language(s)**: Rust, SurrealQL, Python, Shell, Nix
- **License of the reference repo**: NOASSERTION
- **Backend & APIs**: Rust — Core database engine, query parser, execution planner, and network server; Tokio — Asynchronous runtime handling concurrent network IO and storage operations; WebAssembly — Plugin execution sandbox using Wasmtime and WIT bindings
- **Data & persistence**: RocksDB — Embedded persistent key-value storage engine implementation
- **Infrastructure & deploy**: Docker — Multi-stage container packaging for dev and minimal production images; OpenTelemetry — Distributed tracing, metric collection, and OTLP export pipeline
---
## 3. KEY ARCHITECTURAL DECISIONS (audited from https://github.com/surrealdb/surrealdb @ 18971ff)
1. **Modular Key-Value Abstraction Layer**: Decouples the document-graph query engine from storage backends, supporting SurrealKV, RocksDB, and TiKV through unified traits.
2. **WebAssembly Extensibility Engine via Surrealism**: Uses Wasmtime and component models to execute sandboxed user-defined functions safely within query transactions.
3. **Built-in Model Context Protocol Server**: Native rmcp implementation enables direct AI agent querying and structured schema discovery without external middleware.
4. **Vector Search with Native DiskANN and HNSW**: Integrates high-performance vector indexing directly into the storage core for native retrieval-augmented generation.
---
## 4. NON-NEGOTIABLE ARCHITECTURAL GUARDRAILS
1. **Monorepo & Modular Separation**:
   - Structure as a Turborepo monorepo with strict package boundaries:
     - `apps/web`: Application UI, routing, layouts, and server endpoints.
     - `packages/ui`: Shared design tokens, CSS variables, and Radix UI primitive components.
     - `packages/db`: Database schemas, client singleton, declarative migrations, and seed scripts.
     - `packages/config`: Shared TypeScript, ESLint, and build configurations.
2. **Strict Type Safety & Zero `any` Policy**:
   - Enable `strict: true`, `noImplicitAny: true`, and `strictNullChecks: true`.
   - Validate ALL external inputs, API request bodies, and query parameters with **Zod** schemas before execution.
3. **Frontend & Rendering Guidelines**:
   - Isolate interactive UI state to leaf components. Keep core pages lightweight and performant.
4. **Design System & Aesthetics**:
   - Keep every color, radius, shadow and font in a single token file (CSS variables) and consume tokens everywhere; never hardcode hex values in components.
   - Prefer crisp 1px borders and one subtle shadow scale over blurry default shadows. Pair one sans-serif for body/headings with one monospace for tags, badges, metrics, and code.
5. **Data Layer & Reliability**:
   - Write declarative schema definitions with foreign keys, composite indexes on queried filters, and automated timestamp triggers.
   - Use connection pooling and prepared statements for serverless database execution.
---
## 5. STEP-BY-STEP SCAFFOLDING ROADMAP
- **Phase 1: Workspace & Root Config**: Initialize package manager, monorepo configuration (`turbo.json`, `tsconfig.base.json`, `package.json`).
- **Phase 2: Database Schema & Client**: Set up the data layer (RocksDB): client, connection pool, models, and migration scripts.
- **Phase 3: Design Tokens & UI Primitives**: Build accessible `Button`, `Input`, `Card`, `Badge`, and layout wrappers inside `packages/ui`.
- **Phase 4: Core Application Routes & Handlers**: Implement primary authentication, user session handling, and application routes.
- **Phase 5: Quality Assurance & Build Verification**: Run `tsc --noEmit`, ESLint, Prettier, and smoke test suites to ensure zero compilation or runtime errors.
---
## 6. EXECUTION INSTRUCTIONS
1. Review all specifications, architectural guardrails, and stack choices above.
2. Present the full monorepo directory tree structure.
3. Systematically generate the complete, production-ready codebase according to the 5-phase roadmap above — starting with the root workspace setup, followed by the database schema, UI design system package, and full-stack application routes until the repository is fully scaffolded and ready to run.
Scaffolded something with this prompt?
Would you pick this stack for a multi-model real-time database project?

Frequently asked about SurrealDB

Can SurrealDB run as an embedded database in client applications?

Yes, SurrealDB compiles as an embedded Rust crate or WebAssembly module inside browser environments and edge devices.

How does SurrealDB handle live queries and realtime streaming updates?

The server maintains WebSocket subscription channels that monitor transaction commit logs and stream filtered diffs.

One email a month: new deep dives and stack trends

New source-audited architectures, head-to-head comparisons and the monthly stack report. No spam, unsubscribe anytime.

use-this-stack.md