# KuzuDB or general GraphDBs

**URL:** <https://discourse.julialang.org/t/kuzudb-or-general-graphdbs/133139>\
**Category:** Offtopic\
**Created:** [October 14, 2025, 11:33am UTC](https://discourse.julialang.org/t/kuzudb-or-general-graphdbs/133139 "2025-10-14T11:33:26Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 14, 2025, 1:43pm UTC](https://discourse.julialang.org/t/kuzudb-or-general-graphdbs/133139/2 "2025-10-14T13:43:22Z")

</div>

> [@DnBgk](#):
>
> Now Kuzu is still usable. Maybe one should do a [Kuzu.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/Kuzu) package. Or maybe one should look into doing a similar Graph database (in Julia).

I believe it’s at least possible, and Julia might be a very nice language to implement (such) a database in. One has already been done JuliaDB.jl, though it’s now unmaintained, and it wasn’t a graph database. But Julia has I think great graph capabilities in packages, so I wouldn’t rule such a DB out.

> **[Out-of-core processing · JuliaDB.jl](https://juliadb.juliadata.org/latest/out_of_core/)**

I see:

> As of version 0.11.0, a Kuzu database is now just a file on disk instead of a directory. This single-file design makes your Kuzu databases much more portable and easier to share or archive.

It’s unclear to me how large this file is, i.e. is this an “in-memory database”, a sort of oxymoron?

What does KuzuDB give you over e.g. Neo4j that you can use with:

> **[GitHub - virtualgraham/Neo4jBolt.jl: Neo4j Bolt driver for Julia supports Neo4j 3.0 and...](https://github.com/virtualgraham/Neo4jBolt.jl)**
>
> Neo4j Bolt driver for Julia supports Neo4j 3.0 and above

[or Neo4j.jl, though the other driver seems better, maintained, and a replacement.]

Note, written in Julia (at one point I thought it maybe a database, but I didn’t look into it since proprietary, and I believe also using Snowflake for a database):

[https://x.com/relationalai?lang=en](https://x.com/relationalai?lang=en)

> RelationalAI is the industry’s first relational knowledge graph coprocessor for your data clouds, with a mission to empower every decision with intelligence.

While JuliaDB is archived, it depends on MemPool.jl not archived, that might be useful. Also Blobs.jl might also be.

I see also:

> Kuzu is working on something new! .. For those using Kuzu currently, prior Kuzu releases will continue to be usable in the same way without modifications to your code.

So it seems premature to drop KuzuDB, and are they planning a replacement? I’m not sure people would want to make KuzuDB.jl client for an archived profuct that may nothave a future, unless the replacement will be compatible, with same client access protocol.

There’s a lot to think about when making a database, which query language, SQL, or graph-oriented like Cypher or other. I see KuzuDB uses it, same as Neo4j, so maybe something could be reused:

> [@Neo4j Connection](https://discourse.julialang.org/t/neo4j-connection/95031/2):
>
> I stopped using neo4j.jl as I found it buggy and use cypher-shell instead which is quite reliable albeit slow. You can try it out with: cypher-shell -a neo4j://localhost:7687 --format plain -u USER -p PASSWORD 'match (n) return n' where -a specifies the address:port. In julia, you can do read(`cypher-shell -a neo4j://localhost:7687 --format plain -u USER -p PASSWORD 'match (n) return n'`, String) and process manually the resulting string

---

_[View the full topic](https://discourse.julialang.org/t/kuzudb-or-general-graphdbs/133139)._