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
