What this tells me is that the graph db space has a lot of room in it for someone to come along and make a kick ass product, because honestly every time I've had a problem a graph db can solve I remember I basically only have a few mediocre choices to choose from.
Neo4J has been very meh in my experience, but they are the biggest.
I discovered that there is a fork of a previous Neo4j enterprise version known as ONgDB. Don't know if it will have a sufficient pool of maintainers to fix and make evolve such a product. But at least it remains fully open source.(Neo4J enterprise version open source code has been removed..)
I investigated using Neo4j back in 2010 for storing the schedules/routes of ocean shipping freight companies, forwarders, etc. The first cut of the system stored the schedule data in a graph like way in MySQL, but to do recursive SQL queries (needed for the types of queries being performed) was annoying. Things worked well enough, but a graph database would have resulted in a much more logical representation of the data structures being used - and the code behind the queries easier to develop.
That said, the 2nd system never got off the ground, I quit the badly run startup before finishing it. And now that I have a bit more experience with Neo4j, I'd say it would have been a bear to fully implement. Java is too heavy and Neo4j is a memory pig. It works, I can't say it is bad or perhaps iffy like Tinkerpop, but it is "Enterprise Software" and everything that is associated with that meme.
I have been using Tigergraph for my latest research into modeling the schedules etc of rail transport. It is much faster than Neo4j, requires far less memory (I can store every bit of data I need to in it unlike with Neo4 (would need multiple 64GB of RAM servers)), and its programming language is pretty nice once you get the hang of it.
So I'd recommend Tigergraph. The downside is that it is not as 'plug and play' as Neo4j, does not has all the mindshare/fancy bells and whistles, and is entirely C++/Unix based. So having some UNIX sysadmin experience is helpful unless you want to use their cloud solution.
> to do recursive SQL queries (needed for the types of queries being performed) was annoying. Things worked well enough, but a graph database would have resulted in a much more logical representation of the data structures being used
I think there's plenty of room to disagree with this view that modeling graph data in SQL is not "logical enough". Though to be fair, there seems to be some ongoing work on adding some "property"-based layer to bare SQL in order to make common graphs-and-properties oriented queries a bit more ergonomic.
For what I was doing, and how I was doing it, working with graph structures directly with Cypher would have been easier. Perhaps "logical" is the wrong word; my intent was to relay my specific experience, not express a general "principle".
It's not about the databases, it's about the migration in the first place.
If you have a problem that can be solved best with a graph database, then there is no problem. Many problem can be better solved with a graph structure. Choose one, and you'll be happy.
But, if your use-case is migrating from MongoDB to a graph database, that's a bit of a red-flag. What data model do you have where you can migrate from a document/schema-less system to a graph database? Maybe the tech lead figured out that a graph model works better for your data. If that's the case, then great -- migrate away.
But given that they want to go from Mongo to a graph DB, the fear is that this is someone who is only chasing the next cool technology and not solving an underlying business problem.
>But given that they want to go from Mongo to a graph DB, the fear is that this is someone who is only chasing the next cool technology and not solving an underlying business problem.
To be fair to the teach lead, I do feel like it was the other way around. MongoDB was foisted on us on a new project (we were previously SQL) by a software architect who left soon after. I've never felt that MongoDB was a good fit for what we want to do, but I want to return to SQL.
New tech lead pushing switching an existing product from infamously-cargo-culted MongoDB, of the much-hyped-but-now-passed Document Databases Are The Future wave, to either of a couple products in the current "X database architecture is The Future" wave? Does that not read like it could just as well be straight-faced parody, as real? The products may be fine, so far as they go, that's not what I'm trying to puzzle out here.
In my experience MongoDB has only given me problems (either performance or data loss). Most likely when someone wants so "solve" something with MongoDB, there is always a better technology to do it (Cassandra, ScyllaDB, S3!, PostgreSQL/JSONB). I could Imagine that their current implementation has a half modeled graph-like structure in MongoDB and migrating to something else (I am generally against Neo4J because of their horrible pricing tiers).
they are a solid product - graph and document is a good mix. don't listen to the negative postgres fundos (especially ones who don't understand what a solid and performative database Mongo has become)
The most recent graph DB I've used was Dgraph, I've found the interface to be good to work with and it does scale well performance wise. Memory consumption was still too high for my tastes and if you need to build common algos on top like PageRank, again for example, they don't support that out of the box. If you read through their forum you'll see they may never choose to support things like that natively so you have to do things like I did which was export the data out. This was maybe 7 months ago now.
I'll also say that working on the entire graph if you need to is difficult, they're not oriented around working on the whole more like fragments that you've paired down through your query modifiers so if you know you're going to be doing a lot of work that requires you to do things on the entire graph that may change the performance characteristics for you a lot.
I like it and would use it again but there are rough edges to work around still and it is young so know your use case and know the trade offs you're making.
We use ArangoDB and are super happy. But I guess it depends on your use case. We operate in the area of 1 million records. Everything is super fast and the ability to also have search, graph and document workloads was most important for us.
We used ArangoDB at my previous job. I liked it, though it was my first engineering job so I didn't get deep into the technicals. I thought it had a nice UI and query language
Honestly I never heard of it, I had a few in mind but that wasn't one. I'll give it a try next time I need a graph db maybe it can scratch my itch so to speak.
My concerns basically range around memory consumption, query language and language ecosystem.
Edit: Oh and I guess around like functional extensibility. The last time I used a graph DB I had to export from the db itself to HDFS and use Spark to do things like PageRank and I'd rather be able to write that natively in their query lang or some like UDF equivalent.
That's what you can do in Neo pretty easily. The DS library offers a bunch (50+) algorithms to run on the graph data directly or projected, e.g. PR on 117M wikipedia links runs in 20s.
I've had bad experience with Neo4J's memory consumption so I'm wary of that to be honest. I don't disagree that it has those things but we actively chose to go against it because of past issues with resource usage.
Redis is memory-backed, so you have limitations here. When I think of neo4j and its equivalents, it's about super giant datasets that are beyond memory limits.
Neo4J has been very meh in my experience, but they are the biggest.