SurrealDB: multi-model database in Rust with document, graph, and time-series

What is SurrealDB?

SurrealDB is a relatively young multi-model database, developed since 2018 by Tobie Morgan Hitchcock and Jaime Morgan Hitchcock (brothers, UK-based). First 1.0 version 2024, version 2.0 early 2025. In May 2026, version 2.3 is stable and in production at some startups -- but still too young for regulated industries like fiduciary, law, or insurance.

The pitch: a single database for all data models. SurrealDB can simultaneously be relational (with tables, joins, foreign keys), document-based (schemaless JSON-like records), graph (with edges between records), and time-series (with time bucketing). Instead of operating three different databases (Postgres + MongoDB + Neo4j), you have one. That saves operations complexity and data duplication.

License model: Business Source License (BSL) 1.1 with 4-year conversion to Apache 2.0. Concretely: version 1.0 (2024) becomes fully OSS in 2028. Version 2.0 (2025) becomes OSS in 2029. Self-host for companies with < USD 5M ARR is free; above that an enterprise license is needed. For SME self-use no obstacle.

SurrealDB is written in Rust and runs on all platforms (Linux, macOS, Windows, Docker, Kubernetes). Embedded mode (single binary) and cluster mode with TiKV as distributed storage backend. SurrealQL is the proprietary query language -- SQL-like but with graph traversal, schemaless operations, and live queries for real-time subscriptions. JSON-RPC, REST, and WebSocket APIs built-in.

SurrealDB Cloud (surrealdb.com/cloud) offers a free tier with 1 GB storage, start plan from USD 15/month, production tiers with multi-region and backup. EU region (Frankfurt) available.

Why it matters

SurrealDB is the most promising new database technology in May 2026 -- but not yet the default suggestion for Swiss SMEs. Three reasons for observation mode instead of production use.

First: ecosystem maturity. Postgres has 30 years of ORM, migration, and backup tools. SurrealDB is 2 years old (in the 1.0+ phase). Prisma support is beta, SurrealMigrations is primitive, backup tooling is limited to surreal export/import. Anyone building a long-term critical system for 5-10 years has less risk with Postgres in 2026.

Second: SurrealQL lock-in. The proprietary query language is powerful but not portable. A SurrealDB app cannot be easily migrated to Postgres -- you must rewrite all queries. With Postgres-Cockroach migration that is a dump-restore with minimal changes.

Third: no BSL conversion reached yet. Version 1.0 only becomes Apache 2.0 in 2028. Anyone valuing license clarity above all waits. SMEs with < USD 5M ARR are unaffected by BSL anyway.

For which cases is SurrealDB the right choice in 2026? Greenfield experiments, hobby projects, side projects with appetite for new tech, startups in pre-seed phase with pivot probability. Anyone building a system that will be rewritten in 1 year gets real value from SurrealDB multi-model flexibility -- relational tables today, graph edges tomorrow, time-series the day after, all without DB switch.

For Swiss regulated industries (fiduciary, law, insurance, public sector): not yet. PostgreSQL is the right choice in 2026. Reassess SurrealDB in 1-2 years, then version 1.0 is Apache 2.0 and the ecosystem has matured.

How it works

SurrealDB is a single binary running in two modes: embedded (in-process, no server) or server (with JSON-RPC/REST/WebSocket). The data structure is based on "records" -- each record has a unique ID in the form table:id and can contain arbitrary fields (strings, numbers, arrays, objects, references).

An example with SurrealQL:

# Start server surreal start --bind 0.0.0.0:8000 --user root --pass root file://data.db

# Schema and data DEFINE TABLE client SCHEMAFULL; DEFINE FIELD name ON client TYPE string; DEFINE FIELD industry ON client TYPE string ASSERT $value INSIDE ['Fiduciary', 'Law', 'Insurance']; DEFINE FIELD created_at ON client TYPE datetime DEFAULT time::now();

CREATE client:antaco SET name = 'Antaco AG', industry = 'Fiduciary'; CREATE client:weidmann SET name = 'Weidmann Treuhand', industry = 'Fiduciary';

# Graph edge RELATE client:antaco->knows->client:weidmann SET since = time::now();

# Query: all clients in fiduciary industry with their contacts SELECT *, ->knows->client.* AS contacts FROM client WHERE industry = 'Fiduciary';

Schemafull, schemaless, or hybrid: selectable per table whether the schema is strictly validated or arbitrary fields are allowed. Foreign keys via REFERENCE type or graph edges. Indexes via DEFINE INDEX. Vector search via embedding fields with HNSW index.

Live queries: LIVE SELECT * FROM client subscribes to changes in real time via WebSocket. That replaces pub/sub layers like Redis for some realtime use cases.

Client libraries: surrealdb.js (TypeScript), surrealdb.py (Python), surrealdb.rs (Rust), surrealdb.go (Go), surrealdb.java (Java). Prisma support is beta in 2026.

Backup: surreal export/import as JSON, plus file-system snapshot with file:// backend. Cluster backup via TiKV snapshots (more complex). No PITR in May 2026; that is a known gap. Replication via TiKV cluster or Surreal's own multi-node mode (since version 2.2).

SurrealDB to production in 5 steps

1. 01Validate use case: does the project really need multi-model (relational + graph + document + time-series)? If no, prefer Postgres.
2. 02Decide embedded vs. server mode: for single-process apps embedded for performance, for multi-client apps server mode with JSON-RPC/WebSocket.
3. 03Define schema in SurrealQL: SCHEMAFULL for critical data with ASSERT validation, SCHEMALESS for flexible fields. Graph edges via RELATE.
4. 04Backup strategy: surreal export daily to S3-compatible storage (Hetzner Storage Box, MinIO). For TiKV cluster: TiKV snapshot tooling.
5. 05Monitoring: SurrealDB exports Prometheus metrics on /metrics. Grafana dashboard with query latency, live-query count, and storage usage. PITR still missing in 2026.

When to use SurrealDB

The right choice when (a) a greenfield project with multi-model needs is being built (relational + graph + document), (b) live queries for realtime apps are needed, or (c) a team with Rust affinity and appetite for new tech wants to experiment.

Concrete scenarios: a hobby project or side project with appetite for modern DB technology, a startup MVP in pre-seed phase with pivot probability, a social graph (friends, followers, likes) plus time-series (engagement metrics) in one DB, a knowledge graph for AI RAG with entity relations.

Live queries make SurrealDB attractive for realtime dashboards and multi-user collaboration: instead of Redis pub/sub plus DB layer you have both in one component. However: Postgres offers LISTEN/NOTIFY and Supabase Realtime has it too -- the advantage is not unique.

Multi-model is the actual USP. Anyone wanting to build a schema combining relational clients + document metadata + graph relations + time-series events can do that in one DB in SurrealDB. In Postgres you would combine jsonb + recursive CTEs + table partitioning -- doable but more complex.

For production in regulated industries: not yet in 2026. Observe, reassess in 1-2 years.

When not to use

For long-term critical systems with a 5-10 year horizon in regulated industries: not yet in 2026. The ecosystem is too young, backup tooling immature, migration paths unclear. PostgreSQL is the safe default.

For applications that may later want to migrate to other DBs: SurrealQL is not portable, migration to Postgres or MongoDB is a 1-3 month project with query rewrite. Anyone wanting to keep migration options open stays on Postgres with its broad compatibility universe (Cockroach, Supabase, Neon, Aurora).

For setups needing strict data residency or fully OSS license: BSL is a source-available license, not a real open-source license (OSI does not recognize it). Until 2028, version 1.0 is not Apache 2.0.

For simple CRUD applications without multi-model need: SurrealDB is overkill. Postgres suffices and is significantly more proven. SQLite often suffices for single-tenant.

For teams without experience in new technologies: SurrealQL requires a learning curve, operations are not as documented as in mature DBs, Stack Overflow has fewer answers. Anyone needing fast help in a production crisis has a 100x larger ecosystem with Postgres.

Trade-offs

FAQ

Related topics

Sources

1. SurrealDB 2.x release notes · 2026-05
2. SurrealDB License (BSL 1.1) · 2026-04
3. SurrealDB documentation -- SurrealQL · 2026-05
4. SurrealDB Cloud pricing and regions · 2026-05