I've been excited about Kuzu DB as a SQLite-style graph database. It looks like the devs are moving on to something else and no longer will support it, as of 10 October.
Their message reads, "Kuzu is working on something new! We will no longer be actively supporting KuzuDB. You can access the full archive of KuzuDB here: GitHub" https://github.com/kuzudb/kuzu
There was a recent VLDB paper[1] demonstrating that the extension DuckPGQ[2] for DuckDB (an embedded database) offers competitive graph query performance compared to Neo4j and Umbra. No data on how it compares to KuzuDB.
A couple companies using Kuzu in products are talking about joining efforts on a community fork, including Gitlab and Kineviz. Possible future home of that work: https://github.com/Kineviz/bighorn
Strangely enough, it was just that day when I discovered this formidable embeddable graph database that the "archived" banner also appeared. Bummer. I wonder why they stopped as there was a long string of commits for years.
I use the Python Kuzu graph database library, super convenient for local experiments. I see no reason to stop using it. The underlying database is archived on GitHub so it isn’t going anywhere.
If I can't trust their first project (KuzuDB), then why on earth would I trust any subsequent project by them? I won't.
This is why I stick to SQLite or PostgreSQL when it comes to databases. An LLM can trivially write me the commonly necessary graph queries if I should need them.
Rough news on kuzu being archived - startups are hard and Semih + Prashanth did so much in ways I value!
For those left in the lurch for compute-tier Apache Arrow-native graph queries for modern OSS ecosystems, GFQL [1] should be pretty fascinating, and hopefully less stress due to a sustainable governance model. Likewise, as an oss deeptech community, we add interesting new bits like the optional record-breaking GPU mode with NVIDIA Rapids [4].
GFQL, the graph dataframe-native query language, is increasingly how Graphistry, Inc. and our community work with graphs at the compute tier. Whether the data comes from a tabular ETL pipeline, a file, SQL, nosql, or a graph storage DB, GFQL makes it easy to do on-the-fly graph transforms and queries at the compute tier at sub-second speeds for graphs anywhere from 100 edges to 1,000,000,000 [3]. Currently, we support arrow/pandas, and arrow / nvidia rapids as the main engine modes.
While we're not marketing it much yet, GFQL is already used daily by every single Graphistry user behind-the-scenes, and directly by analysts & developers at banks, startups, etc around the world. We built it because we needed an OSS compute-tier graph solution for working with modern data systems that separate storage from compute. Likewise, data is a team sport, so it is used by folks on teams who have to rapidly wrangle graphs, whether for analysis, data science, ETL, visualization, or AI. Imagine an ETL pipeline or notebook flow or web app where data comes from files, elastic search, databricks, and neo4j, and you need to do more on-the-fly graph stuff with it.
We started [4] building what became GFQL before Kuzu because it solves real architectural & graph productivity problems that have been challenging our team, our users, and the broader graph community for years now. Likewise, by going dataframe-native & GPU-mode from day 1, it's now a large part of how we approach GPU graph deep tech investments throughout our stack, and means it's a sustainably funded system. We are looking at bigger R&D and commercial support contracts with organizations needing to do subsecond billion+-scale with us so we can build even more, faster (hit me up if that's you!), but overall, most of our users are just like ourselves, and the day-to-day is wanting an easy OSS way to wrangle graphs in our apps & notebooks. As we continue to smooth it out (ex: we'll be adding a familiar Cypher syntax), we'll be writing about it a lot more.
28 comments
[ 0.25 ms ] story [ 56.3 ms ] threadTheir message reads, "Kuzu is working on something new! We will no longer be actively supporting KuzuDB. You can access the full archive of KuzuDB here: GitHub" https://github.com/kuzudb/kuzu
[0] https://github.com/cozodb/cozo
[1] https://vldb.org/cidrdb/papers/2023/p66-wolde.pdf [2] https://duckpgq.org/
1. https://github.com/oxigraph/oxigraph
Hopefully they will ship cool new things.
https://kuzudb.com/docs/developer-guide/database-internal/
This is why I stick to SQLite or PostgreSQL when it comes to databases. An LLM can trivially write me the commonly necessary graph queries if I should need them.
--
Rough news on kuzu being archived - startups are hard and Semih + Prashanth did so much in ways I value!
For those left in the lurch for compute-tier Apache Arrow-native graph queries for modern OSS ecosystems, GFQL [1] should be pretty fascinating, and hopefully less stress due to a sustainable governance model. Likewise, as an oss deeptech community, we add interesting new bits like the optional record-breaking GPU mode with NVIDIA Rapids [4].
GFQL, the graph dataframe-native query language, is increasingly how Graphistry, Inc. and our community work with graphs at the compute tier. Whether the data comes from a tabular ETL pipeline, a file, SQL, nosql, or a graph storage DB, GFQL makes it easy to do on-the-fly graph transforms and queries at the compute tier at sub-second speeds for graphs anywhere from 100 edges to 1,000,000,000 [3]. Currently, we support arrow/pandas, and arrow / nvidia rapids as the main engine modes.
While we're not marketing it much yet, GFQL is already used daily by every single Graphistry user behind-the-scenes, and directly by analysts & developers at banks, startups, etc around the world. We built it because we needed an OSS compute-tier graph solution for working with modern data systems that separate storage from compute. Likewise, data is a team sport, so it is used by folks on teams who have to rapidly wrangle graphs, whether for analysis, data science, ETL, visualization, or AI. Imagine an ETL pipeline or notebook flow or web app where data comes from files, elastic search, databricks, and neo4j, and you need to do more on-the-fly graph stuff with it.
We started [4] building what became GFQL before Kuzu because it solves real architectural & graph productivity problems that have been challenging our team, our users, and the broader graph community for years now. Likewise, by going dataframe-native & GPU-mode from day 1, it's now a large part of how we approach GPU graph deep tech investments throughout our stack, and means it's a sustainably funded system. We are looking at bigger R&D and commercial support contracts with organizations needing to do subsecond billion+-scale with us so we can build even more, faster (hit me up if that's you!), but overall, most of our users are just like ourselves, and the day-to-day is wanting an easy OSS way to wrangle graphs in our apps & notebooks. As we continue to smooth it out (ex: we'll be adding a familiar Cypher syntax), we'll be writing about it a lot more.
Links:
* ReadTheDocs: SQL <> Cypher <> GFQL - https://pygraphistry.readthedocs.io/en/latest/gfql/translate...
* pip install: https://pypi.org/project/graphistry/
* 2025 keynote - OSS interactive billion-edge GFQL analytics on 1 gpu: https://www.linkedin.com/posts/graphistry_at-graph-the-plane...
* 2022 blogpost w/ Ben Lorica first painting the vision: https://thedataexchange.media/the-graph-intelligence-stack/