A year ago I started working at a mobility startup (pretty much works like an airline) that uses Elixir/OTP as it’s main backend technology - Yay! -.

Having worked on some reservation systems in the past (a java legacy system we inherited about 5 years ago which had a huge relational-table mess with lots of views to represent hotel room availability) this time we decided not to go with a relational model and use instead a graph database. It turns out modeling the whole availability thing (routes and geo-located stations, etas, trips, reservations, people and vehicles) using graphs was much easier for our minds than thinking on lots of joins or views. Actually we spent a few weeks just modeling graphs on a board before actually coding anything, and trying to answer some of the questions we know the API would have to answer. Of course, graph dbs excel at problems where you have lots of relationships, and I wouldn’t recommend them for storing all of your business data, for example we still use Postgres for most of the business stuff like users, payments, reservations, but keep nodes on the GraphDB with the same UUIDs that Ecto generates, and we just store enough data on them as we need for solving the availability search.

One nice thing IMHO is that using Neo4J from Elixir moved me to contribute to both bolt_sips and the underlying boltex driver. Actually many Elixir libs I share on my github have come to life because we use them in a way at work (besides those that are just for fun). And that is nice, I guess, solving real problems cause more libraries to be born and those already existing to become more mature, and the Elixir community benefits from that.

So far using Neo4J has been a nice experience for us. Also OTP has been a very nice choice for us, we basically have a process per vehicle which is basically driving the vehicle with live data (via websockets and graphql subscriptions) to the next station that has either people getting on/off, and we skip those places that no one reserved at. And that in Mexico City can save a lot of time in traffic and a much better experience for our customers.

I have always kept an eye on graph databases and it is really exciting to see some work in using them directly from Elixir!

I am hearing, not directly, Regina is working on an Ecto version, for Neo4j. I contemplated the same at the beginning of my experience with neo4j in Elixir, but realized soon I would just limit the access to Neo4j, and hence went for giving the users a more transparent access to the Neo4j’s own query language; Cypher. And I don’t regret that decision. In fairness, at that time the Model was still a thing, in Ecto, and I didn’t like it very much. Now Ecto is probably much more suitable for trying again, but I let Regina drive this journey, and focus on the lower level Neo4j bindings instead.

I am using neo4j from 2016 oct and found it quite good i used neo4j_sips and with raw query syntax and it’s superb in performance, I didn’t face a single issue in last 2 years with Neo4j, but the thing with Neo4j is you can’t run on cluster in free version, single instance only you can run and the Licence fee is quite higher side so single node only it’ll support with maximum 5 billion nodes, dGraph is better than Neo4j but it’s library of elixir is in alpha stage so I wouldn’t recommend if you are using elixir, (you can use GoLang with DGraph and it’s awesome).

I tried to integrate separate databases for that but at the end of the day you end up having mostly the same data in the two databases… So why don’t use a graph database for all? IMO