Using Surrealism to build your own extensions

The database where storage, context, and memory are one transaction.

The context layer for AI agents

Five databases become one

Stop stitching databases together. SurrealDB unifies your entire context layer in a single multi-model engine - one query language, one transaction, one deployment.

Before - Multiple databases

  • Client: 37ms
  • Your application: 5 SDKs · 5 drivers · 5 connection pools
    • Vector database: Proprietary API
    • Full-text search database: Search DSL
    • Time-series database: InfluxQL / Flux
    • Relational / document database: SQL / MQL
    • Graph database: Cypher / Gremlin
  • Eventual consistency only
    sync?sync?sync?sync?

After - SurrealDB

  • Client: 11ms
  • Your application: 1 SDK · 1 driver · 1 connection pool

The only vertical stack from storage to memory

No other product offers this. Object storage to agent memory. One transaction boundary. One permission model. One deployment.

Spectron

Memory
Your agents remember users, accumulate preferences, and reason over history - no separate memory layer needed.

SurrealDB

Context
Documents, graphs, vectors, and time-series in one ACID transaction. One query gives the agent everything it needs to reason.

Storage

Storage
Distributed storage with quorum consensus. Compute-storage separation, object storage, and elastic scale beneath the context layer.

The architecture

One stack. Four layers. Every layer under one roof.

Spectron 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.

Why it breaks

Agents fail due to context. Not models.

Your model can reason. It just has nothing reliable to reason over. Five systems. Five consistency models. Context that fragments at every seam.

Context that leaks at every seam

Data flows between five systems. Relationships, history, and metadata fragment at every boundary.

Writes that half-succeed

Memory updates in one system, state fails in another. Without unified transactions, partial writes corrupt context.

Latency that compounds

Every system adds a network hop. Round trips stack under load until agents miss their response window.

Five systems to keep alive

Five failure modes, five monitoring setups, five sets of credentials. The glue code becomes the product.

How it works

The read-think-write loop

Read, think, write - in a single transaction.

  • Read
    Graph traversal, vector search, and temporal facts - one SurrealQL statement, one round trip.
  • Think
    Documents, relationships, embeddings, and history arrive together. The agent reasons over complete context.
  • Write
    Persist decisions, update entities, trigger events - one ACID transaction, no partial writes.

Why SurrealDB

Every failure has a structural fix.

Each failure mode has a structural fix - built into the engine, not bolted on top.

  • Context leaks
    Multi-model in one engine
    Documents, graphs, vectors, and time-series are native primitives in one query. No stitching across systems.

  • Partial writes
    ACID across all data models
    Graph updates, document writes, and vector index changes happen in a single transaction. All succeed or none do.

  • Compounding latency
    One query, one round trip
    SurrealQL composes graph traversal, vector search, and temporal filtering in a single statement. No multi-system orchestration.

  • Operational overhead
    Built-in backend
    Auth, permissions, API endpoints, live queries, and event triggers. The database is the backend.

SurrealQL

One query. Every model.

Graph traversals, vector search, transactions, and access control in one expressive language.

Multi-model query

Graph, vector, and temporal data in one round trip.

LET $vec = fn::embed("running shoes");

SELECT
  ->purchased->product AS history,
  ->reviewed->product[WHERE
    vector::similarity::cosine(
      embedding, $vec
    ) > 0.8
  ] AS relevant,
  ->prefs[WHERE valid_at <= time::now()] AS prefs
FROM ONLY $user;

ACID transactions

Multi-model writes succeed together or not at all.

BEGIN TRANSACTION;

LET $order = CREATE order SET
  user = $auth.id,
  product = product:headphones,
  total = product:headphones.price;

RELATE $auth.id->purchased->product:headphones
  SET at = time::now();

UPDATE product:headphones SET stock -= 1;

COMMIT TRANSACTION;

Built-in auth

Authentication and row-level security in the database.

DEFINE ACCESS account ON DATABASE
  TYPE RECORD
  SIGNUP (
    CREATE user SET
      email = $email,
      pass = crypto::argon2::generate($pass)
  )
  SIGNIN (
    SELECT * FROM user WHERE
      email = $email AND
      crypto::argon2::compare(pass, $pass)
  );

DEFINE TABLE order PERMISSIONS
  FOR select WHERE user = $auth.id
  FOR create WHERE $auth.id != NONE;

Use cases

Built for agents

Context-aware agents, persistent memory, knowledge graphs, real-time collaboration - see what teams are building on the context layer.