LadybugDB vs HelixDB
Two modern embedded graph databases with opposite bets: LadybugDB = columnar + Cypher + MIT (the KuzuDB successor). HelixDB = Rust-native graph+vector + HelixQL. Here's how to choose.
TL;DR verdict
Pick LadybugDB if you want Cypher portability, columnar analytics, MIT embedding, and agent-ready OpenAPI/MCP. Pick HelixDB if you live in Rust and want fused vector+graph retrieval in one engine with its custom HelixQL. For regulated-industry agents (legal/medical/finance), LadybugDB's standards + permissive license usually win.
Head-to-head comparison
| Dimension | 🐞 LadybugDB | 🌀 HelixDB |
|---|---|---|
| Positioning | DuckDB for graphs; KuzuDB successor | Rust graph-vector DB for RAG |
| Storage | Columnar, compressed, vectorized — in-memory, disk, or object storage (CSR on object storage via Icebug / GraphLake) | Row-oriented / custom (Rust); in-memory, disk, or object storage |
| Query language | Cypher (portable, standardizing) | HelixQL (custom, graph+vector fused) |
| Vector + full-text search | Native vector & full-text indices alongside the property graph | Native hybrid vector+graph+full-text |
| Range scans | Yes — ART indexes serve exact + range filters (gt/gte/lt/lte/between) with ordered scans | Yes — range indexes over timestamps etc. |
| License | MIT (permissive) | Commercial / AGPL-flavored — check terms |
| Deployment | Embedded zero-deps, server mode (Bolt), ADBC columnar interface; OpenAPI + MCP server | Embedded Rust; local server; managed cloud |
| SDKs | Python, JS/TS (npm), Rust + MCP (PyPI) | Rust-first + JS/Python clients |
| Analytics (scans/aggs) | Excellent (columnar) | Good (not columnar-specialized) |
| Talent pool | Large (Cypher everywhere) | Small (HelixQL-specific) |
| Lineage | VLDB research + 10+ enterprise predecessor | Newer startup project |
| Graph algorithms | 220+ via Icebug (columnar NetworKit fork) on the same CSR data | Thin built-in set; app-side composition |
Setting the record straight
A competitor comparison page claims LadybugDB is "embedded-only, disk-only, no range scans, and wrong for RAG because RAG is OLTP." Every clause is false. The facts:
1. Storage: in-memory, disk, and object storage — including CSR on object storage
LadybugDB traverses CSR whether it lives in native storage, in Parquet files, or in Arrow tables. Relationships can be mounted directly from object storage (S3-compatible) via the open Icebug format (icebug-disk as Parquet CSR, icebug-memory as Arrow CSR for zero-copy) — no import required. The GraphLake vision pairs Iceberg tables with icebug-disk graphs. Storage mode is a workload choice, not a single-process ceiling.
2. Topology: embedded, server (Bolt), and ADBC
LadybugDB runs embedded in-process (zero dependencies, plus WebAssembly for the browser), as a server speaking Bolt, and through ADBC — the Arrow-native columnar interface that hands results to data frames and lakehouse tools without row-by-row conversion. "Embedded by design" never meant "embedded only."
3. Range scans: yes, via ART indexes
LadybugDB's Adaptive Radix Tree (ART) indexes — the same design DuckDB uses for every PRIMARY KEY — keep keys in sorted order, so one index serves exact lookups and range filters with ordered scans in either direction. "What did this agent see between Tuesday and Thursday" is an indexed range scan, not a post-filter.
4. RAG is OLAP, not OLTP — and LadybugDB pairs with your OLTP store
Retrieval over a knowledge graph — multi-hop traversals, vector similarity, aggregations over large candidate sets — is analytical (OLAP) work: scan-heavy, read-mostly, exactly what columnar vectorized engines are built for. High-concurrency transactional writes (OLTP) belong in SQLite or Postgres — and LadybugDB works alongside them just fine, as the analytical brain next to your system of record. Framing RAG as "transactional agent traffic" that needs an OLTP graph engine inverts the workload: agents read far more than they write.
Language check: Cypher vs HelixQL
// LadybugDB — standard Cypher, works on Neo4j/Kuzu too
MATCH (u:User {id: $uid})-[:BOUGHT]->(p:Product)<-[:BOUGHT]-(other)-[:BOUGHT]->(rec)
WHERE NOT (u)-[:BOUGHT]->(rec)
RETURN rec.name, count(*) AS score ORDER BY score DESC LIMIT 10;
// HelixDB — HelixQL fuses vector + traversal (proprietary syntax)
// v:search(embedding) + traversal in one query — powerful but non-portableIf you ever need to hire, audit, or migrate, Cypher's portability is a superpower. Every Cypher engineer is productive on LadybugDB day one.
When HelixDB is the better fit
- Your workload is fused vector + graph retrieval (hybrid RAG) and you want it in one Rust engine.
- Your stack is Rust-first and you accept a custom query language.
- You don't need columnar analytics or MIT redistribution guarantees.
When LadybugDB wins
- Agentic AI in regulated industries needing auditable, permissively-licensed infra.
- Analytical traversals + aggregations over large graphs (fraud, recommendations, knowledge graphs).
- You want Kuzu/Cypher compatibility, OpenAPI + MCP for agents, and npm/PyPI SDKs.
Ecosystem edge: Icebug, icebug-format, and NetworkX go columnar
A new engine means a thin algorithm library and a bet that app-side glue covers the gap. LadybugDB inherits decades of graph-algorithm research instead:
- Icebug: a columnar fork of NetworKit with 220+ graph algorithms running directly on LadybugDB's CSR data — centrality, communities, paths, embeddings, no export step.
- icebug-format: open Parquet-with-CSR storage — graphs on object storage and in the lakehouse (GraphLake), interoperable with the whole Parquet/Arrow world.
- NetworkX goes columnar too: via the
nx-arrowandnx-ladybugbackends, the same columnar tech reaches Python's most popular graph library — prototype in NetworkX, productionize on LadybugDB.
Try the Cypher-native, MIT-licensed option.
One-command install. Migrate from Kuzu, Neo4j, or HelixDB in minutes.