SurrealDB: Multi-Modell-Datenbank in Rust mit Document, Graph und Time-Series

Was ist SurrealDB?

SurrealDB ist eine relativ junge Multi-Modell-Datenbank, entwickelt seit 2018 von Tobie Morgan Hitchcock und Jaime Morgan Hitchcock (Brüdern, UK-basiert). Erste 1.0-Version 2024, Version 2.0 Anfang 2025. Im Mai 2026 ist Version 2.3 stabil und in produktivem Einsatz bei einigen Startups -- aber noch zu jung für regulierte Branchen wie Treuhand, Anwalt oder Versicherung.

Der Pitch: eine einzige Datenbank für alle Daten-Modelle. SurrealDB kann gleichzeitig relational (mit Tabellen, Joins, Foreign Keys), dokumenten-basiert (schemalose JSON-ähnliche Records), Graph (mit Edges zwischen Records), und Zeit-Reihen (mit Time-Bucketing) verwenden. Statt drei verschiedene Datenbanken zu betreiben (Postgres + MongoDB + Neo4j), hat man eine. Das spart Operations-Komplexität und Datenverdoppelung.

Lizenz-Modell: Business Source License (BSL) 1.1 mit 4-Jahres-Konversion auf Apache 2.0. Konkret: Version 1.0 (2024) wird im Jahr 2028 vollständig OSS. Version 2.0 (2025) wird 2029 OSS. Self-Host für Unternehmen mit < USD 5 Mio. ARR ist kostenfrei; darüber braucht es eine Enterprise-Lizenz. Für KMU-Selbstnutzung kein Hindernis.

SurrealDB ist in Rust geschrieben und läuft auf allen Plattformen (Linux, macOS, Windows, Docker, Kubernetes). Embedded-Mode (single-binary) und Cluster-Mode mit TiKV als verteiltem Storage-Backend. SurrealQL ist die proprietäre Query-Sprache -- SQL-ähnlich, aber mit Graph-Traversal, Schemaless-Operations und Live-Queries für Realtime-Subscriptions. JSON-RPC, REST und WebSocket-APIs eingebaut.

SurrealDB Cloud (surrealdb.com/cloud) bietet einen Free-Tier mit 1 GB Storage, Start-Plan ab USD 15 pro Monat, Production-Tarife mit Multi-Region und Backup. EU-Region (Frankfurt) verfügbar.

Warum es wichtig ist

SurrealDB ist im Mai 2026 die vielversprechendste neue Datenbank-Technologie -- aber noch nicht der Default-Vorschlag für CH-KMU. Drei Gründe für Beobachtungs-Modus statt Production-Einsatz.

Erstens: Ecosystem-Reife. Postgres hat 30 Jahre ORM-, Migration- und Backup-Tools. SurrealDB ist 2 Jahre alt (in der 1.0+-Phase). Prisma-Support ist Beta, SurrealMigrations ist primitiv, Backup-Tooling beschränkt sich auf surreal export/import. Wer ein langzeit-kritisches System für 5-10 Jahre baut, hat in 2026 mit Postgres weniger Risiko.

Zweitens: SurrealQL-Lock-in. Die proprietäre Query-Sprache ist mächtig, aber nicht portierbar. Eine SurrealDB-Anwendung kann nicht einfach auf Postgres migriert werden -- man muss alle Queries neu schreiben. Bei Postgres-Cockroach-Migration ist das ein Dump-Restore mit minimalen Änderungen.

Drittens: noch keine BSL-Konversion erreicht. Version 1.0 wird erst 2028 Apache 2.0. Wer Lizenz-Klarheit über alles stellt, wartet ab. KMU mit < USD 5 Mio. ARR sind ohnehin nicht von der BSL betroffen.

Für welche Fälle ist SurrealDB die richtige Wahl 2026? Greenfield-Experimente, Hobby-Projekte, Side-Projects mit Lust auf neue Tech, Startups in der Pre-Seed-Phase mit Pivot-Wahrscheinlichkeit. Wer ein System baut, das in 1 Jahr neu geschrieben wird, hat von SurrealDB-Multi-Modell-Flexibilität einen echten Vorteil -- relationale Tabellen heute, Graph-Edges morgen, Time-Series übermorgen, alles ohne DB-Wechsel.

Für regulierte Branchen in der Schweiz (Treuhand, Anwalt, Versicherung, öffentlicher Sektor): noch nicht. PostgreSQL ist 2026 die richtige Wahl. SurrealDB in 1-2 Jahren neu bewerten, dann ist Version 1.0 Apache 2.0 und das Ecosystem ist gereift.

Wie es funktioniert

SurrealDB ist ein Single-Binary, das in zwei Modi läuft: embedded (in-process, ohne Server) oder server (mit JSON-RPC/REST/WebSocket). Die Datenstruktur basiert auf "Records" -- jedes Record hat eine eindeutige ID im Format table:id, und kann beliebige Felder (Strings, Numbers, Arrays, Objects, References) enthalten.

Ein Beispiel mit SurrealQL:

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

# Schema und Daten DEFINE TABLE mandant SCHEMAFULL; DEFINE FIELD name ON mandant TYPE string; DEFINE FIELD branche ON mandant TYPE string ASSERT $value INSIDE ['Treuhand', 'Anwalt', 'Versicherung']; DEFINE FIELD created_at ON mandant TYPE datetime DEFAULT time::now();

CREATE mandant:antaco SET name = 'Antaco AG', branche = 'Treuhand'; CREATE mandant:weidmann SET name = 'Weidmann Treuhand', branche = 'Treuhand';

# Graph-Edge RELATE mandant:antaco->kennt->mandant:weidmann SET seit = time::now();

# Query: alle Mandanten der Branche Treuhand, mit ihren Kontakten SELECT *, ->kennt->mandant.* AS kontakte FROM mandant WHERE branche = 'Treuhand';

Schemafull, schemaless oder hybrid: pro Tabelle wählbar, ob das Schema strikt validiert wird oder beliebige Felder erlaubt sind. Foreign Keys via REFERENCE-Typ oder Graph-Edges. Indexes via DEFINE INDEX. Vector-Search via embedding-Felder mit HNSW-Index.

Live-Queries: LIVE SELECT * FROM mandant abonniert Änderungen in Real-Time via WebSocket. Das ersetzt Pub/Sub-Layer wie Redis für einige Realtime-Use-Cases.

Client-Libraries: surrealdb.js (TypeScript), surrealdb.py (Python), surrealdb.rs (Rust), surrealdb.go (Go), surrealdb.java (Java). Prisma-Support ist 2026 in Beta.

Backup: surreal export/import als JSON, plus File-System-Snapshot bei file://-Backend. Cluster-Backup über TiKV-Snapshots (komplexer). Kein PITR im Mai 2026; das ist eine bekannte Lücke. Replikation via TiKV-Cluster oder Surreal-eigenen Multi-Knoten-Modus (seit Version 2.2).

SurrealDB in 5 Schritten produktiv

1. 01Use-Case validieren: braucht das Projekt wirklich Multi-Modell (relational + Graph + Document + Time-Series)? Falls nein, Postgres bevorzugen.
2. 02Entscheidung Embedded vs. Server-Mode: bei Single-Process-Apps Embedded für Performance, bei Multi-Client-Apps Server-Mode mit JSON-RPC/WebSocket.
3. 03Schema in SurrealQL definieren: SCHEMAFULL für kritische Daten mit ASSERT-Validierung, SCHEMALESS für flexible Felder. Graph-Edges via RELATE.
4. 04Backup-Strategie: surreal export täglich in S3-kompatiblen Speicher (Hetzner Storage Box, MinIO). Bei TiKV-Cluster: TiKV-Snapshot-Tooling.
5. 05Monitoring: SurrealDB exportiert Prometheus-Metriken auf /metrics. Grafana-Dashboard mit Query-Latenz, Live-Query-Count und Storage-Usage. PITR fehlt 2026 noch.

Wann SurrealDB einsetzen

Die richtige Wahl, wenn (a) ein Greenfield-Projekt mit Multi-Modell-Bedarf gebaut wird (relational + Graph + Document), (b) Live-Queries für Realtime-Apps gebraucht werden, oder (c) ein Team mit Rust-Affinität und Lust auf neue Tech experimentieren möchte.

Konkrete Szenarien: ein Hobby-Projekt oder Side-Project mit Lust auf moderne DB-Technologie, ein Startup-MVP in Pre-Seed-Phase mit Pivot-Wahrscheinlichkeit, ein Social-Graph (Freunde, Follower, Likes) plus Time-Series (Engagement-Metriken) in einer DB, ein Wissensgraph für KI-RAG mit Entity-Relations.

Live-Queries machen SurrealDB attraktiv für Realtime-Dashboards und Multi-User-Collaboration: statt Redis-Pub/Sub plus DB-Layer hat man beides in einer Komponente. Allerdings: Postgres bietet LISTEN/NOTIFY und Supabase Realtime hat das auch -- der Vorteil ist nicht einzigartig.

Multi-Modell ist der eigentliche USP. Wer ein Schema bauen will, das relationale Mandanten + Document-Metadaten + Graph-Beziehungen + Time-Series-Events kombiniert, kann das in SurrealDB in einer DB. In Postgres müsste man jsonb + Recursive CTEs + Tabellen-Partitionierung kombinieren -- machbar, aber komplexer.

Für Production in regulierten Branchen: noch nicht 2026. Beobachten, in 1-2 Jahren neu evaluieren.

Wann NICHT

Für langzeit-kritische Systeme mit 5-10 Jahres-Horizont in regulierten Branchen: noch nicht 2026. Das Ecosystem ist zu jung, Backup-Tooling unreif, Migrations-Pfade unklar. PostgreSQL ist die sichere Default-Wahl.

Für Anwendungen, die später potenziell auf andere DBs migrieren möchten: SurrealQL ist nicht portierbar, Migration auf Postgres oder MongoDB ist ein 1-3-monatiges Projekt mit Query-Rewrite. Wer Migrations-Optionen offen halten will, bleibt bei Postgres mit dessen breitem Kompatibilitäts-Universum (Cockroach, Supabase, Neon, Aurora).

Für Setups, die strenge Datenresidenz oder vollständige OSS-Lizenz brauchen: BSL ist eine Source-Available-Lizenz, keine echte Open-Source-Lizenz (OSI erkennt sie nicht an). Bis 2028 ist Version 1.0 nicht Apache 2.0.

Für einfache CRUD-Anwendungen ohne Multi-Modell-Bedarf: SurrealDB ist Overkill. Postgres reicht und ist deutlich bewährter. SQLite reicht oft sogar für Single-Tenant.

Für Teams ohne Erfahrung mit neuen Technologien: SurrealQL erfordert Lernkurve, Operations sind noch nicht so dokumentiert wie bei reifen DBs, Stack Overflow hat weniger Antworten. Wer in einer Production-Krise schnell Hilfe braucht, hat bei Postgres ein 100x grösseres Ecosystem.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

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