We will no longer be actively supporting KuzuDB • Hacker News Board

Re: We will no longer be actively supporting KuzuDB

#41

Post by adsharma » Sun, Oct 12, 2025, 9:55 PM UTC

aftbit wrote: post #33

adsharma wrote: post #26

Earlier quoted context omitted.

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...

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…

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.

Re: We will no longer be actively supporting KuzuDB

#42

Post by pinkmuffinere » Sun, Oct 12, 2025, 10:22 PM UTC

aaa_aaa wrote: post #30

m00dy wrote: post #22

Earlier quoted context omitted.

Kuzu means sheep in turkish.

Not sheep, lamb.

TIL sheep != lamb

Re: We will no longer be actively supporting KuzuDB

#43

Post by lmeyerov » Sun, Oct 12, 2025, 10:28 PM UTC

scosman wrote: post #4

Oh too bad. Small fast embedded graph DBs are rare. Any good alternatives?

Posted below: GFQL is also OSS and architecturally similar, though slightly different goals and features: https://news.ycombinator.com/item?id=45560036#45561807

Re: We will no longer be actively supporting KuzuDB

#44

Post by aftbit » Mon, Oct 13, 2025, 12:13 AM UTC

adsharma wrote: post #41

aftbit wrote: post #33

Earlier quoted context omitted.

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…

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) a…

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.

Re: We will no longer be actively supporting KuzuDB

#45

Post by jabr » Mon, Oct 13, 2025, 12:29 AM UTC

OutOfHere wrote: post #35

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.

Re: We will no longer be actively supporting KuzuDB

#46

Post by jabr » Mon, Oct 13, 2025, 12:34 AM UTC

redpink wrote: post #5

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

Re: We will no longer be actively supporting KuzuDB

#47

Post by jabr » Mon, Oct 13, 2025, 12:37 AM UTC

Ultimatt wrote: post #20

https://duckdb.org/community_extensions/extensions/duckpgq.h...

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.

Re: We will no longer be actively supporting KuzuDB

#48

Post by adsharma » Mon, Oct 13, 2025, 3:26 AM UTC

aftbit wrote: post #44

adsharma wrote: post #41

Earlier quoted context omitted.

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) a…

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.

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".

Re: We will no longer be actively supporting KuzuDB

#49

Post by rowanG077 » Mon, Oct 13, 2025, 10:15 AM UTC

SoftTalker wrote: post #37

OutOfHere wrote: post #35

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.

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.

Re: We will no longer be actively supporting KuzuDB

#50

Post by dtenwolde » Mon, Oct 13, 2025, 11:16 AM UTC

Ultimatt wrote: post #20

https://duckdb.org/community_extensions/extensions/duckpgq.h...

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.