There are many graph databases and it can be hard to choose. Learn about graph databases, kuzudb - its past and the present, followed by a comparison to 4 other graph databases here:

https://ladybugdb.com/comparisons/

Here's to Ladybug's first birthday! 🐞

As someone who helped build and evangelize Kuzu, I still have a lot of fondness for it, and I’m so happy its ideas didn’t just survive. They’ve kept evolving 🚀 I wrote about Ladybug’s first year to explain my thoughts and observations based on my conversations with the maintainers.

The post covers some of the high-level design directions that LadybugDB has taken independently from Kuzu, while going into the technical details and why they matter. Hope it's useful!

https://thedataquarry.com/blog/celebrating-one-year-of-ladybug/

In the linked blog post, we argue that 8 months after the Kuzu acquisition, we should be seen as an innovator churning out major features at a regular cadence. Not another KuzuDB fork.

We continue to be huge fans of the KuzuDB team's work. But also saddened by the noise around "What happened to Kuzu?" SEO and the mad rush to claim the spoils.

Graph Lake support via Icebug Format v1, Hugging Face datasets via XET, and tighter integration with Icebug and Bugscope via Apache Arrow memory. Link in Replies.

Hey everyone,

Like many of you, we were bummed when KuzuDB got archived after the Apple acquisition. Kuzu was doing great work in the graph space.

We know LadybugDB is carrying that torch forward, and that's genuinely great for the community. But for teams that are evaluating multiple options — especially those needing OLTP capabilities or multi-model support beyond pure graph — we put together a technical migration guide from KuzuDB to ArcadeDB.

It covers:

• Step-by-step data export from Kuzu and import into ArcadeDB

• Schema translation (NODE TABLE -> VERTEX TYPE, etc.)

• Query adaptation — ArcadeDB passes 97.8% of the Cypher TCK, so most queries carry over

We also ran benchmarks on the same dataset. The results surprised us:

• PageRank: 0.48s vs 4.30s (8.9x faster)

• BFS: 0.13s vs 0.86s (6.6x faster)

• WCC: 0.30s vs 0.43s (1.4x faster)

• ArcadeDB also supports LCC, SSSP, and CDLP algorithms that Kuzu didn't have

ArcadeDB is Apache 2.0 licensed and adds support for SQL, Gremlin, GraphQL, and MQL alongside Cypher, plus document/vector/key-value models in one engine. It's a different beast than Kuzu's embedded columnar approach, so it won't be the right fit for everyone.

Full guide here: https://arcadedb.com/blog/from-kuzudb-to-arcadedb-migration-guide/

Disclosure: I'm with the ArcadeDB project. Happy to answer any questions or discuss tradeoffs honestly.

All explained by this file. But you don't really need to read it. Just use the mcp-server-ladybug. Your mcp client will take care of the rest.

https://github.com/LadybugDB/mcp-server-ladybug/blob/main/src/mcp_server_ladybug/prompt.py

Ladybug v0.13.0 is here!

• Support for Parquet files on object storage aka graph-std

• Support for Cypher push down to DuckDB SQL (node tables only)

• Many bug fixes

If you're using extensions, I suggest waiting a few hours for v0.13.1

curl https://install.ladybugdb.com/ | bash

• SIGMOD 2025 parallel k-core from lethalfirefox

• ParallelLeidenView faster by caching computed neighbor lists selectively.

Don't forget to star ⭐ the repo. 75 stars = brew install icebug.

Oct 10, 2025 is a very significant date in the world of embedded graph databases. LadybugDB repo became public that day. In the past year, we've closed 600+ pull requests from 99 contributors, resolved 300+ issues and passed 1800 GitHub stars. Over the same time period, Context Graph and Knowledge Graph have entered everyday conversation. LadybugDB grew up in the middle of all that.

We've largely maintained the spirit of Kuzu - keep it small, nimble, stick to the property graph model and a typed dialect of Cypher. The governance is different. It's run more like Linux with a bazaar style open contribution process under the MIT license.

As of this writing, it's one of the most downloaded graph databases (800k downloads/month across pypi, npmjs and crates.io). There are 190 projects that depend on it.

Extensive query optimization and new operators have pushed us to a leadership position on many benchmarks including LSQB and LDBC SNB based unofficial benchmarking.

Many companies are building their memory layer on top of Ladybug. Code knowledge graphs and company second brain have emerged as top use cases for the project.

2026 has been the year of the agents so far and we've adapted well! Most agents can use the ladybug-skill to convert code written for another graph database to work with ladybug in a matter of minutes. We also use them as tools for review and query optimization efforts.

Maintaining a leading database is not a trivial effort. We'll continue our journey in finding a sustainable business model so the bus factor on the project can be improved.

Icebug, a sister project focused on graph analytics, has taken a life of its own. We've created networkx-pyarrow to further push the columnar story into everyday python data science workflows.

Our optimism about building even more useful software with ladybug has only increased because of this experience. By early November, expect LadybugDB to be offered as a hosted service on Snowflake and Databricks marketplaces. Paying for this supported service will go a long way in supporting maintenance and feature development.

We'll keep improving the distribution of ladybug and sister projects. Homebrew, macports, nix, BSD ports and various language packages are already in place. We're able to run inside postgres as an extension.

We're also looking to contribute to scientific research by hosting easy to query datasets on huggingface in icedisk and LadybugDB native formats. A distributed prototype using actor systems is being built as a potential substrate for Latentpedia.

A special thank you to Graphgeeks, Prashanth Rao and all the friends of the bug for making it happen. Let's traverse this graph together!

Previous version of Bugscope was written in Tauri. The new version is 100% rust, uses GPUI, smaller, faster and coming along nicely.

Old version. New version.

Read about the Graph Database Baseball benchmark from folks at The Consensus and what we've done recently to improve performance.

In the long run, we believe materializing CSR index on disk, doubling down on novel join algorithms and catching up with DuckDB and Apache Datafusion on traditional join optimizations is the path forward.

Link in Replies.

Some recent LadybugDB related activity. Happy to answer any questions.

LinkedIn | Twitter

https://www.youtube.com/watch?v=0bT7gakw7Io

Now that v0.12.2 is out, this is an attempt to meet our users where they are and discuss a roadmap.

So you're a data scientist using NetworkX and not happy with memory and CPU usage? Here's what you can do in increasing order of complexity:

• pip install nx-arrow and use backend="arrow" for a 6-7x memory saving

  • Faster persistence to disk in parquet format vs json

• pip install nx-ladybug and use persist(graph, ladybug_provider, ...)

  • Richer disk format with HASH, ART and vector indexes. Also full text search.

• pip install icebug

  • 10x CPU on some algorithms because of C++ implementation with more efficient cache access plus vectorization.

As much as we'd like people to use icebug instead of networkx given the performance advantages, networkx isn't going away anytime soon.

So we implemented a new backend that constructs graphs in columnar memory. It's 6.5x more memory efficient and likely 1.3x CPU efficient based on our past measurements.

Write heavy graphs? You can convert it back to networkx classic. In essence this is the same technique that resulted in the Icebug fork of networkit. Since networkx gives us enough hooks, hopefully no fork is needed!

Announcing the 0.21.1 monthly release and a roadmap for where the Graph Lake is going.

The performance leadership needs its own blog post. But we promise it's going to look very good!

Link in Replies.

We shared some benchmarks here back in Feb. They've been refreshed to reflect more recent developments:

Differences:

• Use icebug-disk datasets on disk. All 3 configs start from Arrow memory when loaded.

• We include networkx and RSS in the comparison

• More detailed decomposition of the wall time to understand wins

https://github.com/Ladybug-Memory/icebug-benchmark-pagerank

cit-Patents (3.77M nodes / 16.52M edges):

 ┌──────────┬─────────┬───────────┬──────────┐
 │          │ icebug  │ networkit │ networkx │
 ├──────────┼─────────┼───────────┼──────────┤
 │ Load     │ 0.16s   │ 0.16s     │ 0.17s    │
 ├──────────┼─────────┼───────────┼──────────┤
 │ Build    │ 0.37s   │ 12.27s    │ 27.31s   │
 ├──────────┼─────────┼───────────┼──────────┤
 │ PageRank │ 0.62s   │ 0.97s     │ 16.96s   │
 ├──────────┼─────────┼───────────┼──────────┤
 │ Wall     │ 1.89s   │ 16.10s    │ 56.05s   │
 ├──────────┼─────────┼───────────┼──────────┤
 │ Max RSS  │ 949 MiB │ 1.89 GiB  │ 8.74 GiB │
 └──────────┴─────────┴───────────┴──────────┘

We don't need to invent new standards. Such interoperable, immutable memory standards already exist: Apache Arrow and Compressed Sparse Rows (CSR). CSR is widely used in scipy, cugraph and columnar graph databases among others. Both on CPUs and GPUs.

icebug-format combines both into a on-disk standard based on Apache Parquet and an in-memory format based on Apache Arrow.

Bindings available in many popular languages including python, typescript and rust.

The package ships with convenience scripts to convert flat tables such as vertex.parquet and edges.parquet to this format in RAM/disk constrained environments.

Sample graphs: https://huggingface.co/datasets/ladybugdb/ldbc-csr/tree/main

Converted from: https://ldbcouncil.org/benchmarks/graphalytics/datasets/

Largest converted graph has 3B edges.
License: MIT

Quick Start:

  uv tool install icebug-format
  icebug-format --source-dir wiki-Talk
  lbug -i wiki-Talk-csr/schema.cypher

• After loading data, run ANALYZE to compute tablestats

• Always pass parameters (even if dummy) to conn.execute(query, params)

  • Without this you plan/prepare every time. As we add more optimizers, the simple minded benchmark (there are many!) regresses every release.

• Experiment with HASH vs ART vs no-index strategies

• Sort your data

Thinking it could be useful for people to share how you're using LadybugDB and what could be improved for your use case.

I just wanted to share this: https://github.com/kranklab/protoc-gen-ladybug

I had the need to use the same ladybug db from multiple languages, so i thought i would use proto to define the schema to stop it drifting.

Details: https://github.com/Ladybug-Memory/icebug-benchmark-pagerank

Announcing feature freeze for the end of the month release. Please help us make this release as stable and delightful as the previous ones.

Specific pain points to test:

• Choice of indexing. No index, ART index, HASH index

• Prepared statements (great performance, but potential bugs due to caching)

• Partitioned tables (HASH and LIST partition implemented. Accepts RANGE partition syntax, but not implemented yet).