We will no longer be actively supporting KuzuDB(kuzudb.com)
kuzudb.com
We will no longer be actively supporting KuzuDB
https://kuzudb.com
67 comments
Abandoned for a new project. Kuzu is Japanese for unwanted/useless scraps or garbage, so I suppose it's still living up to its name.
For anyone who's curious—the project was originally named after the Sumerian word for "wisdom"[1].
1. https://web.archive.org/web/20250318034702/https://blog.kuzu...
1. https://web.archive.org/web/20250318034702/https://blog.kuzu...
Wow the Japanese were pretty savage back then.
The kana spelling (which is what phonetically would sound like 'kuzu') can refer to either scraps/garbage, or the Kudzu plant.
Kuzu means sheep in turkish.
Not sheep, lamb.
TIL sheep != lamb
Sheep is a superset of lamb. Lamb is a subset of sheep.
So it is correct to say sheep ≠ lamb, or at least sheep !== lamb.
So it is correct to say sheep ≠ lamb, or at least sheep !== lamb.
oh sorry, misremember :)
gitlab just announced knowledge graph with kuzu db. i wonder how it will turns out
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
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
Oh too bad. Small fast embedded graph DBs are rare. Any good alternatives?
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.
[1] https://vldb.org/cidrdb/papers/2023/p66-wolde.pdf [2] https://duckpgq.org/
[1] https://vldb.org/cidrdb/papers/2023/p66-wolde.pdf [2] https://duckpgq.org/
There used to be a similarly names one called CozoDB[0] which was pretty awesome but it looks like its development significantly slowed down.
[0] https://github.com/cozodb/cozo
[0] https://github.com/cozodb/cozo
You should check FalkorDB https://github.com/falkordb/falkordb
Not embedded last I checked. Unless that changed.
Oxigraph[1] is an option, though it's RDF/SPARQL-based rather than property graph/cypher
1. https://github.com/oxigraph/oxigraph
1. https://github.com/oxigraph/oxigraph
Another potential one: new and not ready for primetime yet, but from the Lance team so it's promising: https://github.com/lancedb/lance-graph
Posted below: GFQL is also OSS and architecturally similar, though slightly different goals and features: https://news.ycombinator.com/item?id=45560036#45561807
Perhaps dgraph if using go. Or surrealdb, though it's the opposite of small - it's an all in one, do everything db. I'm excited to see how it matures
SurrealDB: https://surrealdb.com/
“Cloud native” - not embedded
Correction: there is an embedded mode. https://surrealdb.com/docs/surrealdb/embedding
Fork it and organize support for it.
Someone linked to some duckdb extension above that shows some graph support.
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.
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.
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.
Why does an MIT-licensed open source project owe you anything whatsoever?
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.
It's not about what is owed; it's about what can be trusted. The people behind Kuzu have shown that they cannot be trusted to be used.
I don't see why. Every project periodically decides what features they will move forward with and what features they will drop. Some users will have built dependencies on those dropped features. That's their problem, not the software project developers.
Python dropped or changed a lot of things between Python 2 and Python 3, creating a lot of rework for a lot of users. Are they not to be trusted as a project? Is every project obligated to support every feature they ever released, forever, to be considered trustworthy?
To quote from the MIT license: THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND
Python dropped or changed a lot of things between Python 2 and Python 3, creating a lot of rework for a lot of users. Are they not to be trusted as a project? Is every project obligated to support every feature they ever released, forever, to be considered trustworthy?
To quote from the MIT license: THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND
Huh. Your examples are not relevant because they do not apply to killing a project altogether, let alone to killing your very first project. Kuzu did both.
They tried something hard and it didn’t work out. In the process they did some great work. Plus they gave it all away for free, allowing literally anyone in the world to continue the work. They are awesome.
If the rest of us criticized people making open source like you do, there wouldn’t be any.
If the rest of us criticized people making open source like you do, there wouldn’t be any.
That's not how open source adoption works. For open source to get used, people have to trust that it will be maintained. The people behind Kuzu ruined any trust in them. This is also why people prefer established choices over the fashion of the day.
No that's exactly how open source works. They are under zero obligation to wake up tomorrow and continue to work on it. Everyone is lucky they open sourced it, and anyone else is welcome to pick it up where they left off. Contributing a impressive piece of work the community is an accomplishment.
Disparaging them and suggesting people should not trust them in the future for not providing ongoing maintenance, when that was never part of the OSS deal, shows a misunderstanding of what OSS is. Pay them for a maintenance contract, or don't expect maintenance. Stop complaining they didn't fulfill some social contract that existed only in your head.
Disparaging them and suggesting people should not trust them in the future for not providing ongoing maintenance, when that was never part of the OSS deal, shows a misunderstanding of what OSS is. Pay them for a maintenance contract, or don't expect maintenance. Stop complaining they didn't fulfill some social contract that existed only in your head.
It's not necessary to think of it as a social contract, and I never said there was one. Your imagining it doesn't make it so.
It merely is one of several predictors of whether something is sufficiently reliable for use. In the case of Kuzu, its authors have demonstrated that they're not to be trusted.
It merely is one of several predictors of whether something is sufficiently reliable for use. In the case of Kuzu, its authors have demonstrated that they're not to be trusted.
Link to kuzudb internals:
https://kuzudb.com/docs/developer-guide/database-internal/
https://kuzudb.com/docs/developer-guide/database-internal/
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.
They already took it down, unfortunately.
This URL works for now: https://kuzudb.github.io/docs/developer-guide/database-inter...
It is up on the github pages site/domain. At least it was a smooth transition.
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.
More on this here:
https://adsharma.github.io/beating-the-CAP-theorem-for-graph...
https://adsharma.github.io/beating-the-CAP-theorem-for-graph...
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.
> [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.
That's right - it was a fun 2 out of 3 analogy.
The real question being raised in the blog post is - should the next generation graph databases pursue a local-only embedded strategy or build on top of object storage like many non-graph and vector embedded databases are doing.
Specifically, DuckLake (using system catalog for metadata instead of JSON/YAML) is interesting. I became aware of Apache GraphAr (incubating) after writing the blog post. But it seems to be designed for data interchange between graph databases instead of designing for primary storage.
The real question being raised in the blog post is - should the next generation graph databases pursue a local-only embedded strategy or build on top of object storage like many non-graph and vector embedded databases are doing.
Specifically, DuckLake (using system catalog for metadata instead of JSON/YAML) is interesting. I became aware of Apache GraphAr (incubating) after writing the blog post. But it seems to be designed for data interchange between graph databases instead of designing for primary storage.
I only mentioned it because I clicked it wondering if someone had found a way to "cheat" CAP for graph databases. When I saw that it was being used as an analogy and not literally, I figured I'd comment.
I still don't quite get the analogy. What are the 2 out of 3 that you can have? The second paragraph I quoted gives a classic 1 out of 2 dilemma - either scalable _or_ open-source.
I still don't quite get the analogy. What are the 2 out of 3 that you can have? The second paragraph I quoted gives a classic 1 out of 2 dilemma - either scalable _or_ open-source.
DuckDB is scalable (can handle TPC-H 1TB) and open source, but doesn't support graphs natively. It supports some graph queries on a SQL native columnar storage.
With the proposed solution, you'll be able to query larger graphs on an open source graph native engine. Thus beating the "CAP theorem for graphs".
With the proposed solution, you'll be able to query larger graphs on an open source graph native engine. Thus beating the "CAP theorem for graphs".
The code to implement this was open sourced today:
https://github.com/LadybugDB/ladybug/pull/3
https://github.com/LadybugDB/ladybug/pull/3
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.
One thing you might want to watch out for is that the storage format on disk is not stabilized.
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.
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.
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.
Kuzudb was actively working on their cloud/enterprise solution and talking with people signing up for it. Wonder if the timing is related
Reposting:
--
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/
--
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/
With property graphs being adopting in the SQL standard, this isn’t surprising.
The fact that GQL is now supported by some of the relational Database, doesn't mean they'll become an alternative to native Graph Databases.
Yeah I guess it’s like saying that relational DBs supporting native JSON type meant the end of NoSQL DBs.
>relational DBs supporting native JSON type meant the end of NoSQL DBs
This holds true for 95% of cases of well-made software.
This holds true for 95% of cases of well-made software.
It pretty much did except for very specific use cases
Yeah, so sad as a contributor and downstream user.
Hopefully they will ship cool new things.
Hopefully they will ship cool new things.
kuzu is a great project.