Why SurrealDB
Multi-model database for graphs, documents, and real-time
The Problem
Modern applications need multiple data models. User profiles are documents. Social connections are graphs. Transactions are relational. Real-time updates require subscriptions.
Traditional approach: one database per model.
PostgreSQL for relational. MongoDB for documents. Neo4j for graphs. Redis for pub/sub. Each database is another service to deploy, monitor, backup, and secure. Each requires different query languages, different ORMs, different mental models.
This complexity compounds. A single feature might touch three databases. A bug might span multiple systems. Operational overhead grows linearly with database count.
We needed a database that:
- Handles documents, graphs, and relations in one system
- Supports real-time subscriptions natively
- Uses a query language that spans all models
- Runs embedded or as a service
Current Options
| Option | Pros | Cons |
|---|---|---|
| PostgreSQL + ExtensionsRelational core with JSON, graph (AGE), and more. |
|
|
| Neo4jThe established graph database. Cypher query language. |
|
|
| SurrealDBMulti-model: documents, graphs, relations, real-time. |
|
|
Future Outlook
Multi-model databases represent the future for most applications.
The single-model era is ending.
Applications don't fit neatly into "relational" or "document" or "graph." Real data is all of these. The artificial separation into multiple databases creates complexity that multi-model databases eliminate.
SurrealDB is betting on this future. One query language (SurrealQL) that handles records, graph traversals, and real-time subscriptions. One database that scales from embedded to distributed.
Neo4j remains the answer for graph-heavy workloads at scale.
When graph queries dominate, when you need maximum graph performance, when you're processing billions of relationships—Neo4j's specialization wins. SurrealDB is our default; Neo4j is in the toolbox for when we need it.
Our Decision
✓Why we chose this
- True multi-modelDocuments, graphs, and relations are first-class. Not bolted-on extensions.
- SurrealQLOne query language for all models. Graph traversals and document queries in the same statement.
- Real-time subscriptionsLive queries built-in. No separate pub/sub system needed.
- Deployment flexibilityEmbedded for development, server for production, distributed for scale.
×Trade-offs we accept
- MaturityYounger than PostgreSQL or Neo4j. Production stories are fewer.
- Graph performance ceilingFor graph-heavy workloads at massive scale, Neo4j may outperform.
- Ecosystem sizeFewer ORMs, tools, and integrations than established databases.
Motivation
We chose SurrealDB because it eliminates database proliferation.
Our data model includes users (documents), relationships (graphs), transactions (relational), and notifications (real-time). Traditional approach: four databases. With SurrealDB: one.
This isn't about SurrealDB being best at each model. It's about reducing operational complexity. One backup strategy. One monitoring system. One query language. One mental model.
The scale-up path is clear.
SurrealDB handles our current scale. When graph workloads grow to the point where specialized performance matters, Neo4j is ready. The architecture supports this: SurrealDB for most data, Neo4j for graph-intensive analysis.
This choice is honest: we're still learning.
SurrealDB is newer than our other choices. We're betting on the multi-model approach and the team behind it. If that bet doesn't pay off, our data is portable. The decision is pragmatic, not permanent.
Recommendation
Use SurrealDB for:
- Application data: User profiles, settings, content
- Relationship graphs: Social connections, hierarchies, dependencies
- Real-time features: Live updates, collaborative features
- Unified data layer: When you'd otherwise need multiple databases
Use Neo4j when:
- Graph queries are the primary workload
- You need maximum graph performance at scale
- Enterprise features (clustering, security) are required
Start with SurrealDB. Add Neo4j for specific graph-heavy services if needed.
Examples
-- SurrealQL: Documents, graphs, and relations in one language
-- Define user as a document
DEFINE TABLE user SCHEMAFULL;
DEFINE FIELD name ON user TYPE string;
DEFINE FIELD email ON user TYPE string;
DEFINE FIELD settings ON user TYPE object;
-- Define graph relationship
DEFINE TABLE follows SCHEMAFULL;
DEFINE FIELD in ON follows TYPE record<user>;
DEFINE FIELD out ON follows TYPE record<user>;
DEFINE FIELD since ON follows TYPE datetime;
-- Create users
CREATE user:alice SET name = 'Alice', email = 'alice@example.com';
CREATE user:bob SET name = 'Bob', email = 'bob@example.com';
-- Create relationship (graph edge)
RELATE user:alice->follows->user:bob SET since = time::now();
-- Query: Find who Alice follows (graph traversal)
SELECT ->follows->user.name FROM user:alice;
-- Query: Find followers of followers (2-hop graph)
SELECT ->follows->user->follows->user.name FROM user:alice;
-- Real-time subscription
LIVE SELECT * FROM user WHERE email ~ 'example.com';SurrealQL handles documents (user), graphs (follows relationship), and real-time subscriptions in one unified language. No joins across databases.
import Surreal from 'surrealdb.js';
const db = new Surreal();
async function init() {
// Connect to SurrealDB
await db.connect('http://localhost:8000/rpc');
await db.use({ namespace: 'app', database: 'main' });
// Create a user (document)
const user = await db.create('user', {
name: 'Alice',
email: 'alice@example.com',
settings: { theme: 'dark', notifications: true },
});
// Create a relationship (graph)
await db.query(`
RELATE user:${user.id}->follows->user:bob
SET since = time::now()
`);
// Subscribe to real-time updates
await db.live('user', (action, data) => {
console.log('User changed:', action, data);
});
}SurrealDB TypeScript client. Documents, graphs, and real-time subscriptions through one connection.