01 |THE DIFFERENCE
Where Neo4j is read-tuned, SurrealDB is built for live data
Neo4j is optimised for read-heavy graph workloads. SurrealDB is designed for continuously updated graphs and multi-model workloads at scale.
Built for graphs that change
Neo4j is tuned for read-heavy traversal over an in-memory page cache, and sustained writes churn it. SurrealDB's write path is designed for concurrent updates across nodes and sustained throughput.
Documents and vectors beside the graph
Neo4j is a single-model store of nodes, relationships and properties. SurrealDB keeps the graph beside documents, vectors, relations and time-series, queried together.
Horizontal writes without composite databases
Each Neo4j database has one write leader, and write scaling means partitioning across composite databases. SurrealDB scales reads and writes horizontally with compute separated from storage.
02 |THE SAME QUERY
Similar documents, from one team, this quarter. A procedure call and a pattern match in Cypher. One statement in SurrealQL, on one index set.
Neo4j (Cypher)
1// Cypher: the vector index as a procedure call, then the traversal
2CALL db.index.vector.queryNodes('doc_embedding', 10, $q)
3YIELD node AS d, score
4MATCH (d)<-[:AUTHORED]-(:Person)-[:MEMBER_OF]->(:Team {id: $team})
5WHERE d.published > datetime() - duration('P90D')
6RETURN d.title, score
7ORDER BY score DESC;
SurrealQL
1-- SurrealQL: the similarity and the path, together
2SELECT
3 title,
4 vector::similarity::cosine(embedding, $q) AS score
5FROM document
6WHERE embedding <|10|> $q
7 AND <-authored<-person->member_of->team CONTAINS $team
8 AND published > time::now() - 90d
9ORDER BY score DESC;
03 |HOW IT COMPARES
How SurrealDB and Neo4j differ
AI applications need live data, continuous updates and complex retrieval, which pushes read-optimised graph stores to their limits.
04 |DIGITAL TWINS
Graph plus everything else. Telemetry, documents, vectors and geography beside the graph, in one engine.
Walk, join, score and bound in one statement
Neo4j models the graph of a digital twin well. Telemetry, configuration documents, semantic search, geospatial state and scenario branching usually mean further systems and a sync layer. SurrealDB holds all of them in one engine and one query language. Read more in the digital twins use case.
-- One query: walk the graph, join recent telemetry,
-- score similar incidents by vector, restrict by geography.
SELECT
id, name, status,
->depends_on->asset.{ id, name, status } AS upstream,
(SELECT value, recorded_at FROM reading
WHERE asset_id = $parent.id AND metric = "vibration"
ORDER BY recorded_at DESC LIMIT 3) AS recent_readings,
(SELECT id, summary, vector::distance::knn() AS dist
FROM incident_report
WHERE embedding <|3|> $manual_chunk) AS similar_incidents
FROM asset
WHERE kind = "compressor"
AND geo::distance(location, (-1.6, 53.8)) < 25000;
TRUSTED BY
Enterprise teams building on SurrealDB
Neo4j,answered
THE PLATFORM
Everything an application and its agents know. Five surfaces, one engine.
Database
Document, graph, vector, time-series and relational in one engine.
Agent Memory
What an agent learns, with its source and its time, in the same engine.
Cloud
Dedicated clusters by region, or serverless on SurrealDB Earth.
Studio
Query, explore and design the schema from the browser.
MCP
Every model that speaks MCP reaches the database and the memory directly.
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.
VP of Engineering, Later
GET STARTED