LadybugDB vs Neo4j
Neo4j invented the property-graph market. But if you're shipping agents, edge deployments, or per-tenant graphs, do you still want a server cluster with GPL/commercial licensing? LadybugDB is DuckDB for graphs: embedded, columnar, Cypher-compatible, MIT.
TL;DR verdict
Keep Neo4j for large shared clusters, GDS algorithms, and Bloom tooling. Choose LadybugDB for embedded/serverless, columnar analytics, MIT embedding, zero-ops cost, and agent-native OpenAPI/MCP. Most Cypher ports directly.
Head-to-head comparison
| Dimension | π LadybugDB | π© Neo4j |
|---|---|---|
| Architecture | Embedded, in-process (DuckDB-style) | Client-server cluster / Aura cloud |
| Storage | Columnar, compressed, vectorized | Row-oriented transactional store (JVM) |
| Runtime | Native C++ β zero-deps binary, no GC, predictable latency | JVM (Java) β heap sizing, GC pauses, ~GB footprint before your data |
| Query language | Cypher β (portable) | Cypher + GDS procedures β |
| License | MIT (embed & distribute freely) | GPL (Community) / Commercial (Enterprise/Aura) |
| Ops | Zero β a file on disk | Cluster ops, backups, sizing, upgrades |
| Cost model | Free + optional support | License / Aura consumption |
| Analytics scans | Excellent (columnar) | Good; GDS for algorithms |
| Scale-out | Scale-up per instance (edge/tenant) | Clustering, Fabric, Aura |
| Agent interface | OpenAPI + MCP server + SDKs | Bolt drivers + LangChain integrations |
| Graph algorithms | 220+ via Icebug (columnar NetworKit fork) on the same CSR data, zero-copy | GDS library (mature, server-side, licensed) |
| Best for | Agents, edge, per-tenant, regulated embed | Shared enterprise graph platform |
Cost & license: the real decider
Neo4j Community's GPL restricts commercial embedding; production teams land on Enterprise or Aura β per-core or consumption billing that grows with every tenant. LadybugDB's MIT license lets you ship the engine inside your product (legal-tech, medical, finance) with no per-seat meter, plus optional enterprise support when you need an SLA.
Benchmarks: Ladybug wins 26 of 30 queries vs Neo4j
Independent evidence β not vendor numbers. Prashanth Rao (ex-Kuzu team) at The Data Quarry, βCelebrating one year of LadybugDBβ (Oct 10, 2026), maintains an unofficial 30-query benchmark on the LDBC Social Network Benchmark (SF1: ~3.2M nodes, ~17.3M relationships), comparing LadybugDB 0.21.1 vs Kuzu 0.11.3 vs Neo4j 2025.12.1 Community. Result:
| Standout query | Neo4j | LadybugDB | Speedup |
|---|---|---|---|
| Q20 (deep traversal) | 393.3 ms | 14.1 ms | 27.9Γ faster |
| Q30 (heavy aggregation) | 1055.2 ms | 88.7 ms | 11.9Γ faster |
| Q4 | 3.14 ms | 0.38 ms | 8.2Γ faster |
| Q2 | 5.08 ms | 1.18 ms | 4.3Γ faster |
| Q23 | 3.08 ms | 0.73 ms | 4.2Γ faster |
Why it wins: CSR-native execution (counting from CSR metadata, COUNT_EXTEND_CHAIN without materializing paths β a 7-hop chain counting ~179M paths dropped from 5.6s to 0.11s), extend-chains instead of hash-joining full relationship scans, fan-out-aware planning, and relationship semi-masks. Neo4j stays ahead on a handful of queries (notably Q7) β but the overall picture is decisive. Full table + methodology: thedataquarry.com/blog/celebrating-one-year-of-ladybug β
The JVM tax: why Java was the wrong foundation
Neo4j runs on the JVM β and you pay for it on every deployment. Gigabytes of heap before storing a single node. Garbage-collection pauses injecting tail-latency spikes into traversals that should be microseconds. Slow cold starts, mandatory heap tuning (-Xmx roulette), and a runtime that fights containers, edge devices, and serverless instead of disappearing into them. Object headers and pointer-heavy record layouts bloat every node and edge versus a packed columnar layout.
LadybugDB is native C++: a zero-dependency binary that embeds in-process with deterministic latency, minimal footprint, and no runtime to babysit β the DuckDB playbook applied to graphs. Compiled languages (C++ here, Rust elsewhere) hold a structural advantage in embedded environments: predictable performance, tiny binaries, and memory you spend on your graph, not on the runtime's bookkeeping. The JVM made sense for enterprise middleware in 2007. It is overhead you should no longer accept in a database.
Ecosystem edge: Icebug, icebug-format, and NetworkX go columnar
Neo4j's GDS library is mature β but it lives behind the cluster wall, on a row store, under a commercial license. LadybugDB answers with an open ecosystem bet:
- Icebug: a columnar fork of NetworKit shipping 220+ graph algorithms (centrality, community detection, paths, embeddings) that run directly on LadybugDB's CSR data β no export, no second engine, no license meter.
- icebug-format: open Parquet-with-CSR storage. Your graph lives in the lakehouse (Iceberg tables + icebug-disk graphs = GraphLake) and stays readable by every Parquet/Arrow tool. No proprietary store-in.
- NetworkX goes columnar too: the same ideas are reaching Python's most popular graph library via the
nx-arrowandnx-ladybugbackends β larger-than-RAM, columnar-backed graphs in plain NetworkX code. Learn once, scale everywhere.
Migration: Neo4j β LadybugDB
- Export:
apoc.export.csv.*or Parquet dumps of nodes + edges. - Re-create schema:
CREATE NODE TABLE Person(name STRING, PRIMARY KEY(id))β thenCOPY ... FROM. - Port Cypher: most
MATCH/WHERE/RETURN, aggregations, and variable-length paths work as-is. Replace APOC/GDS-specific procedures with app code or LadybugDB equivalents. - Repoint drivers: swap Bolt for the
ladybugdbPython/JS package or OpenAPI; agents can use the MCP server directly.
// Runs on both Neo4j and LadybugDB
MATCH (p:Person)-[:TRANSFERRED_TO*2..5]->(q:Person)
WHERE p.riskScore > 0.8
RETURN p.name, q.name, length(shortestPath((p)-[*]->(q))) AS hops
LIMIT 100
Ditch the cluster. Keep the Cypher.
Embedded, columnar, MIT. Install LadybugDB in one command.