Show HN: SparrowDB, SQLite of graph DB, written in Rust, Cypher compatible

Show HN: SparrowDB, SQLite of graph DB, written in Rust, Cypher compatible(github.com)

2 points by ryaker 46 days ago | 1 comment

SparrowDB is an embedded Cypher graph database written in Rust. It links into your process the way SQLite does.

I built it because I wanted a graph DB without running Docker or a cloud instance.

SparrowDB kicks butt at point lookups, global COUNT(*), and top-10 by degree but lags on traversals (1-hop, 2-hop, and variable-length paths).

It's an embedded engine with no parallel execution vs a warmed JVM server with a mature query planner. The traversal workload is not the target. Agents, CLIs, serverless functions that need a knowledge graph without provisioning one, that's the target.

Cold start is ~27ms. If you're in a serverless context where Neo4j's startup time is disqualifying, that matters.

Bindings for Python, JavaScript/Typescript, and Ruby. All open the same on-disk format. Built-in MCP server for Claude Desktop. A Bolt protocol server was just added, so gdotv and other Bolt clients can connect. At-rest encryption with XChaCha20-Poly1305. MIT.

https://sparrowdb.dev Demo: https://www.loom.com/share/0dffc9274f5f4338878fe0ffa61f0f4e

thitami 45 days ago |

The SQLite comparison is the right framing. The embedded graph DB space has been missing something you can just drop into a process without ops overhead — Neo4j is great until you're building a CLI or serverless function and don't want to provision a server for it. The 27ms cold start is compelling for serverless. Curious how the traversal performance scales with graph size — is the lag on 1-hop/2-hop paths a fundamental architecture constraint or something you expect to close with query planner work?