Skip to content

Extensions

Rust. Write your functions in Rust, with its types and tooling.
WebAssembly. Compile once and run inside the engine, sandboxed.
Query access. Full access to your data from within the function.

01 |WASM SANDBOXING

Isolated by design

Each call creates a fresh WASM instance with its own memory. A module reaches SurrealDB only through explicit host functions, and data crosses the boundary by serialisation.

SurrealDB Engine
Query engine
Parses and executes SurrealQL
Transaction context
Shared ACID boundary
WASM Sandboxno filesystem · no direct DB · no raw network
Module code
User-defined Rust compiled to WASM
Isolated memory
Own store and instance per call

02 |BUILD PIPELINE

How extensions work

Write in Rust, compile to WebAssembly with the SurrealDB CLI, load into your instance, call from SurrealQL.

Functions
fn return_ten() -> i32 { 10 } fn is_positive(n: i32) -> bool { n >= 0 }
Use #[surrealism] to expose functions:
#[surrealism] fn return_ten() -> i32 { 10 } #[surrealism] fn is_positive(n: i32) -> bool { n >= 0 }
surrealism.toml
[package] organisation = "surrealdb" name = "demo" version = "1.0.0"
Compile with SurrealDB CLI
surreal module
command
Rust code ready
to compile to WASM
Compiled extension
module
SurrealDB instance
Create file location with
DEFINE BUCKET
Access the compiled extension module with
DEFINE MODULE
Access functions inside SurrealDB
CREATE person SET num = mod::test::return_ten(); SELECT id, mod::test::is_positive(num) AS is_positive FROM person;

03 |ZERO-DOWNTIME UPGRADES

Hot-load, with the instance up

Deploy, upgrade or roll back a module on a running instance. In-flight requests finish on the previous version while new requests load the update from storage.

DEFINE MODULE OVERWRITE ml;
Cache invalidation
cache.remove(&lookup) - evicts the compiled Runtime
In-flight requests
Continue on Module v1 Arc<Runtime> stays valid
New requests
Cache miss → load from bucket Build new Runtime, cache it
Complete normally
Old runtime dropped when done
Module v2 live
Zero downtime transition

04 |TRANSACTION SAFETY

Same transaction, same commit

A module that calls back into SurrealQL runs in the transaction that invoked it, so its writes, the host callbacks and the original query commit or roll back as one.

CREATE person SET score = mod::ml::predict(data);
Single ACID transaction
Query engine
Parses SurrealQL, finds mod::call
WASM module executes
mod::ml::predict() runs in sandbox
Host callback
__sr_sql("SELECT * FROM training_data") Runs in same ctx and opt - same transaction
Result returned
Module returns prediction, query continues
COMMIT
Query + module writes + host callbacks - one atomic unit

THE PLATFORM

Everything an application and its agents know. Five surfaces, one engine.

IN PRODUCTION

Trusted at scale. Samsung, Nvidia, Verizon, Tencent and Walmart run on SurrealDB.

14,000+

Developers building on SurrealDB Cloud

4M+

Developers building on SurrealDB worldwide

FROM THE TEAMS

SurrealDB gives us a foundation where we can unify semantic search, knowledge graphs, and AI-driven decision making without stitching together multiple systems. Collapsing responsibility into SurrealDB has become our default engineering posture.
Justin Foley

VP of Engineering, Later

GET STARTED

Start building extensions. AI and application logic inside SurrealDB, as WebAssembly.

SurrealDB

The context and memory layer for AI agents

Database. Graphs, vectors, documents and relational data in one engine, in a single ACID transaction.
Agent Memory. Connects and retrieves context wherever your data lives, every fact carrying its source.
Cloud. Fully managed, in the cloud provider and region you choose.

Explore with AI

Copyright © 2026 SurrealDB Ltd. Registered in England and Wales. Company no. 13615201

Registered address: 3rd Floor 1 Ashley Road, Altrincham, Cheshire, WA14 2DT, United Kingdom

Trading address: Huckletree Oxford Circus, 213 Oxford Street, London, W1D 2LG, United Kingdom