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.

You should check FalkorDB https://github.com/falkordb/falkordb

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

Someone linked to some duckdb extension above that shows some graph support.

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

can you share a link?

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

Kuzu means sheep in turkish.

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.

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

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.