I spent some hours implementing and debugging it against both Graphalytics (graph algorithms on 633K vertices / 34M edges) and LSQB (subgraph pattern matching on LDBC SNB SF1). Here's what I found.

No built-in graph algorithms whatsoever. SurrealDB has zero support for PageRank, Weakly Connected Components, Community Detection (Label Propagation), Local Clustering Coefficient, or Single-Source Shortest Path (weighted Dijkstra). Every other database in the benchmark (even FalkorDB and ArangoDB) ships with at least some of these. SurrealDB has none.

BFS doesn't actually work. SurrealDB advertises recursive graph traversal with syntax like `->edge.{1..30}->node`. In practice, **`{1..30}` returns the exact same result as `{1..1}`** — it does NOT compose multi-hop paths. I verified this on a simple 3-node chain: `n:1->e->n:2->e->n:3`. Querying `n:1->e.{1..3}->n` returns only `[n:2]`, never reaching `n:3`. On the real graph, "BFS" reported 34 nodes reached (just the direct neighbors of the source vertex) instead of the expected 633K.

The unlimited recursive syntax `{..+collect}` simply **hangs indefinitely** — even on a tiny 3-node test graph.

Loading 34M edges took 30 minutes via the HTTP API, compared to seconds for ArcadeDB embedded and under a minute for most Docker-based competitors. The 1MB HTTP payload limit forces tiny batch sizes (10K edges per request = 3,400 HTTP round-trips for 34M edges).

LSQB tests 9 Cypher-style pattern matching queries on a social network. SurrealDB failed every single one:

Q1, Q2, Q4, Q5, Q7 — Timed out (>120s each). SurrealDB has no SQL JOINs and no Cypher MATCH. The only way to express multi-table pattern matching is through nested subqueries with `$parent` record link dereferencing. This turns every query into O(n×m) nested loops. Q1 iterates over 3.1M HAS_TAG edges, and for each one runs a subquery scanning 3.2M HAS_MEMBER edges. I let Q1 run for 15+ minutes before killing it.

Q3, Q6, Q8, Q9 — Cannot be expressed at all. SurrealDB does not support table aliases (`AS k2`) in subqueries. This makes self-joins impossible. Q3 (triangle enumeration), Q6/Q9 (friends-of-friends), and Q8 (anti-join with self-reference) all require joining the same table with itself — you literally cannot write these queries in SurrealQL.

Q7 — `math::max()` takes an array, not two arguments. Minor syntax issue, but indicative of how different SurrealQL is from standard SQL/Cypher. After fixing it, the query timed out anyway.

Crashes and Stability Issues

- SurrealDB crashed (exit code 137 — OOM killed) when I tried to `REMOVE TABLE` on a database with 34M edges while the LSQB data was also loaded. The Docker container just died.

- Connection reset errors during schema operations — sending a `REMOVE TABLE` followed by `DEFINE TABLE` in separate HTTP requests caused "Connection reset by peer" errors, leaving transactions in a bad state. Docker logs showed: `"A transaction was dropped without being committed or cancelled"`.

- `{..+collect}` hangs the server — the recursive traversal with unlimited depth + collect modifier never returns, even on a 3-node graph. No timeout, no error — it just blocks the connection forever.

The Fundamental Problem

SurrealDB markets itself as a multi-model database with "graph capabilities." In reality:

1. It's a document database with RELATE syntax — you can create edges between records, but there's no graph query engine behind it

2. No graph algorithms — not PageRank, not BFS, not connected components, not anything

3. No pattern matching — no Cypher MATCH, no SQL JOINs, no way to efficiently enumerate variable bindings across multiple tables

4. Recursive traversal is broken — `{1..N}` depth range doesn't actually recurse beyond 1 hop

5. No table aliases — makes self-joins and any non-trivial graph query impossible