Who’s using graph databases today?

I’ve been exploring a bunch of Neo4j, trying to get my head around Cypher for a couple weeks. I have a bunch of luck using the Boltx package;

I’m unsure if I’ll use Neo4j in the long run because I think it’s being outpaced by some of the competitors. I’m eager to see if the experience on Dgraph is more mature, and I came across Tinkerpop as a unified ecology for all of these graph explorations. This page on Tinkerpop seems to index all of the modern graph DB options:

Chime in if you are using graph DBs in 2025, I’d be glad to see if there could be LiveBook smart cells someday soon.

Yes it is. I have jut released version 2.0 which has some significant improvements and has even more powerful functionality!

I’ve added precompiled versions of kuzu_nif, so you can use KuzuDB without installing a Rust compiler on your computer. Attempt at adapting KuzuDB's Rust crate into Elixir via NIF, any tips/thoughts? - #19 by bgoosman. The advantage of KuzuDB is no server required. It’s all embedded.

I’m contemplating kicking off a hobby project with ArangoDB as the main database.

@TomGrozev is your driver still maintained? It has impressive amount of features

https://github.com/georgfaust/falkordb_ex

The thing should work, but its surely not production ready.
Let me know how it goes.

Hi @Sebb, would love to check out Elixir-falkordb-client!

I’m using a graph database as an appliacation database (just a prototype for now).
My requirements were that I do not need to setup a server and that I can do simple snapshots for undo-redo. afaik there is only one graph-db that is suitable for that: redisgraph (or since that is discontinued: https://www.falkordb.com)

I wrote a Elixir-falkordb-client (should also work with redisgraph) if anyone is intereseted I can open-source it.

(I also tried bolt-sips but for some reason it does not work with falkordb, though it should)

Hello! I’ve been working on a fork of Bolt Sips for the past 3 months. You can find the project at:
https://github.com/sagastume/boltx
It provides support for the latest versions of Neo4j and Bolt. Personally, I’ve been conducting tests with Neo4j Aura.

During this period, I made numerous changes to Bolt Sips, including refactoring PackStream, protocol, socket, and more. The idea behind these changes is to make the implementation as simple as possible, making it easy to adapt to future modifications.

Feel free to try it out and let me know if everything is working smoothly

Compatibility with Neo4j versions: 3.0.x/3.1.x/3.2.x/3.4.x/3.5.x/4.x/5.9 - 5.13.0
Compatibility with Bolt versions: 1.0/2.0/3.0/4.x/5.0/5.1/5.2/5.3/5.4

Thank you for such an informative reply! I thought perhaps the streaming could have been enabled by a novel implementation hiding underneath that addressed the packet/transport issue, but if the folks at Neo4j called it out as an intractable degradation, I trust their assessment (and yours, too ;-p).

If I remember correctly all drivers implement streaming atop of the pull n feature introduced with bolt 4.0.

The issue with the transport code is that until neo4j 5.0, the server would buffer small records and emit packets only when the buffer was filled. Then, when they rewrote the server code (with netty I believe) they ditched the buffering and started emitting packets for each record, regardless of the record size. This is a known issue that will affect all drivers, according to them, it’s not much of an issue in real life scenarios since records would typically be larger (details Potential performance regression in neo4j 5.x with bolt, maybe linked to buffering · Issue #13045 · neo4j/neo4j · GitHub ). When, writing the driver that means, unfortunately, that it’s pretty much impossible to write code that consumes records efficiently for every scenario (basically if you were to set active once for each packet, with small records, you’d do it in a very tight loop leading to really bad performance).

Regarding streaming, m_bolt does support the pull n feature, but it doesn’t concern itself further with it (this will be handled at the neo4_ex level). m_bolt being inspired by mint, there is a way to receive records (by the calling process), which means it’s possible -in theory - to process records as they come. The issue here is that records should only be considered final when they’re followed by a success message, meaning that implementers of higher level drivers using this feature will need to be careful. In any case those won’t fix the issue with large amounts of small records.

Edit : the numbers provided in the github issue aren’t meant to compare drivers performance.