Who’s using graph databases today?

I guess you refer at least to Neo4J. In the past, I did some experiments using bolt_sips, but as you say, it seems not to have been updated for Neo4J version 5.*.

It is indeed a pity that this is happening.

Did you try the other options provided in Exploring Graphs with Elixir?

I’m currently working on a new driver for neo4j that will support v 5+. I’m still ironing out a few things but I hope I’ll be able to release it by the end of June or so.

In the mean time neo4j v 3 and v 4 can still be downloaded. If you don’t use the commercial version, the feature set is rather stable.

In case it’s helpful, here’s some documentation crosswalking Neo4j database version with Bolt protocol version compatability: Bolt Protocol and Neo4j compatibility - Bolt Protocol

Bolt_sips seems to currently top out its support at Bolt v3, and it sounds like @krstfk has maybe stepped up to backfill maintenance & support for more recent protocol versions.

The dream I have is that, since so much has already been done by the Elixir community in terms of Postgres, Apache AGE (https://age.apache.org/) could be the impetus for more robust Cypher/graph support in Ecto, which could have spillover to Neo4j usage. But that’s just a dream I’m not sure will ever materialize.

The thing is that there’s an impedance mismatch between Ecto and graph databases. I believe Dominique Vassard has done some work to provide an ecto like interface on top of bolt_sips but I’m not convinced it may work as is. I believe he also has done some work taking inspiration from ecto.

That being said, one of the things that needs ironing out on my side is providing a repo construct (which is harder than initially thought because clustering is very much a necessity for a driver for neo4j).

By the way Florin Patrescu has stated a while back that he was not able to maintain bolt_sips anymore. And I would like to make it very clear that I have not started a new project because of any issues I had with bolt_sips or any of its maintainers. The thing is when bolt_sips started (and even a couple of years ago), the bolt protocol was poorly documented and now the situation is much different which may lead to radically different design decisions and incompatibilities, which is why I have opted to work on a new driver (hopefully released by the end of June) that will definitely owe a lot to Florin Patrescu and all of the bolt_sips contributors.

Thanks for the update and for sharing your thought process! When i was sleuthing, my trail turned up cold after a January comment in a GH Issue for bolt_sips, and everything you’ve stated makes perfect sense about starting from scratch-ish.

I’m well aware of Dominique’s work and the challenges inherent to it (but I’m glad you mentioned them so others can benefit from learning about them too). While I appreciate and do not discount the journey that led him to evolve his efforts from ecto_neo4j to seraph, I also believe that having more eyes and minds on the problem would allow for finding the surface area for tractable integration solutions for Ecto, even if it isn’t 100% coverage of the problem space available to a graph database engine because of any mismatch. That’s why I feel there could be potential coming out of Ecto adapters for Apache AGE, which actually would require context-switching between SQL and Cypher. But i hear you: it’s not necessarily a simple thing, which is why i temper my hopes.

Sorry about that, the whole thing turned out to be way more difficult than I initially anticipated.
But I’m kind of hopeful now. While I’m still not sure the api is sound/good, I guess I’ll find out when people start using it.
While I’d love a rich ecosystem, right now my goals are speed and flexibility. One of the thing I really want is the ability for the user to provide their own encoding/decoding functions for so called bolt structs (meaning the ability to translate a node with label x into eliixir sruct y). That would avoid having to traverse and convert a list of results. Another goal is to have support for back pressure. I’ve actually split the concerns into two libs, one -inspired by mint- handles a single connection and the encoding/decoding, the other one closer to bolt_sips will handle pooling, routing and all of that.
The first lib is close to completion but needs a bit more tests, the second one needs a bit more work.

If possible, I would like to help.

I foresee myself using elixir long into the future. I also plan to utilize graph databases increasingly.

I even considered attempting to forge my own new library that can utilize neo v5.

But I’m a bit green to tackle that solo.

However, I believe I can be of great value helping someone more senior.

The Arango database is really good and I’d recommend you check it out. Shameless plug I made the ArangoDB adapter for Ecto: GitHub - TomGrozev/arangox_ecto: An ArangoDB Ecto adapter using ArangoX · GitHub

It has full graphing support and works really well with Ecto. In the next release ArangoSearch functions will also be available.

Hi everybody,

This is a quick update to let you know that I’m still very much working on the project. However I got side tracked and working on libs for general consumption turned out to be harder than expected.

As a result, I’ll release a couple of libs on github before any hex release. My hope is to get feedback from the community before the hex releases.

I’m mainly working on two libraries (names subject to change):

• m_bolt : a very thin implementation of the bolt protocol supporting versions 1 to 5.3 (currently). I’m now working on a third (and last) iteration. The m in the name is an hommage to mint because it’s a process less library (and the transport code was stolen from mint). The goals here are efficient decoding and maintainability (bolt is a moving target). A side effect of the redesign is that it’ll be possible to translate bolt structs into elixir struct at the decoding stage. m_bolt will not provide any pooling nor routing support (apart from allowing to setup server side routing).

• neo4_ex : built on top of m_bolt and db_connection, which aims to be close to what bolt_sips provided.

Status :

• I’m fairly happy with the decoder in m_bolt and I believe further optimizations will bring diminishing returns.
• The api for m_bolt has gotten cleaner, if a bit verbose (but that shouldn’t matter for most users).
• The transport code is so/so because from neo4j 4.2 onward, the buffering of the records has been dropped which means that you get blasted with very small packets if you do eg match (n) return n where n is small. I haven’t been able to find a solution to this issue.
• neo4_ex : at first I’ll only have a functional but maybe awkward support for routing. (Neo4j now supports multiple databases, each could get its own routing table).

I’m very sorry for the delays.

Re. the question of this thread, I’ve started using Memgraph (via the bolt_sips lib, which is intended for neo4j but works perfectly well so far thanks to the compatible query language / API) and enjoying it so far, the built-in algorithms are handy, plus the catalogue of extra ones you can pull in (even though they’re in python, wonder if this is somewhere where Nx could come into play at some point?)