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
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.
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.
My best guess is the company was acqui-hired and will soon be working on implementing Kuzu's tech in a different database owned by the acquirer.
My _hope_ is that it was some IP issue with the University of Waterloo and a new company will appear shortly and pretty much pick up where they left off, but that's probably just wishful thinking on my part.
How did you interpret this person comment as about being owed anything? It's simply a fact of life that it's not smart to put your eggs into an unstable basket.
Note that the repo mentions "some of our resources are moving from our website to GitHub: "Docs: http://kuzudb.github.io/docs, Blog: http://kuzudb.github.io/blog" but those links currently redirect to kuzudb.com. I presume they won't be covering the domain name costs in the future and that the transition is in-progress.
Hi there, leading DuckPGQ developer here :) Thanks for the shoutout! I've been busy working on an internship at DuckDB labs so DuckPGQ has gotten less attention, but I'll get back to it soon (December most likely) and will update the extension to support DuckDB v1.4.0 and v1.4.1 this week hopefully.
PGQ requires you to write using SQL and read using a graph query language. GQL is a standalone language that supports reads/writes. But much of the community is still using cypher.
As far as I can tell, this has nothing to do with CAP theorem or distributed systems. It's just being used as an analogy.
> [CAP theorem] states that any distributed storage system can provide only two of these three guarantees: Consistency, Availability and Partition safety.
> In the realm of graph databases, we observe a similar “two out three” situation. You can either have scalable systems that are not fully open source or you can have open source systems designed for small graphs. Details below.
(the article follows)
> This is one solution to the CAP theorem for graphs. We can store a billion scale graph using this method in parquet files and use a free, cheap and open source solution to traverse them, perform joins without storage costs that are prohibitively high.
DuckPGQ is an interesting option, but unfortunately, that project hasn't been touched in a few months and does not currently work with the latest version of DuckDB.
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.
Readit News
1. https://web.archive.org/web/20250318034702/https://blog.kuzu...
Dead Comment
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
[1] https://vldb.org/cidrdb/papers/2023/p66-wolde.pdf [2] https://duckpgq.org/
[0] https://github.com/cozodb/cozo
1. https://github.com/oxigraph/oxigraph
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.
My _hope_ is that it was some IP issue with the University of Waterloo and a new company will appear shortly and pretty much pick up where they left off, but that's probably just wishful thinking on my part.
https://kuzudb.com/docs/developer-guide/database-internal/
More on this here:
https://adsharma.github.io/beating-the-CAP-theorem-for-graph...
> [CAP theorem] states that any distributed storage system can provide only two of these three guarantees: Consistency, Availability and Partition safety.
> In the realm of graph databases, we observe a similar “two out three” situation. You can either have scalable systems that are not fully open source or you can have open source systems designed for small graphs. Details below.
(the article follows)
> This is one solution to the CAP theorem for graphs. We can store a billion scale graph using this method in parquet files and use a free, cheap and open source solution to traverse them, perform joins without storage costs that are prohibitively high.
https://github.com/LadybugDB/ladybug/pull/3
Last few releases, you couldn't open a file written by a previous version of kuzu. You had to constantly export/import as new versions were released.
This is no longer a problem for kuzu because development has stopped. But any open source fork needs to think about how to stabilize storage.
In the past few releases kuzu switched from database as a directory to a single file database.