[oscarcp]

We would have saved so many wasted hours in the last company I worked for if we had this... you have no idea, to give you a sense, the decision to move from a Neo4J db to MySQL (the service was failing, the DB was failing, it was a bad architecture decision) took 6 months, when it should have been at most a couple days discussion.

Nurture this, it will become a great tool in the belt for a lot of people

[smnc]

Do you mind me asking, what kind of problems did you run into with Neo4j? Did you encounter performance issues after the DB grew to a certain size, or did you realize that the data wasn't suited to a graph DB and weird query patterns started causing trouble, or was it something else entirely?

I'm considering using a Neo4j self hosted instance for a project, but having only played around with it in low-stakes + small-data toy projects, I'm not really familiar with the footguns and failure modes...

All that aside, plugging holes in a sinking database for six months because you can't come to a descision does not sound like a fun time :D

[oscarcp]

It was a "compound" error you can say.

The first mistake was management not wanting to pay for Neo4J, so we were working in production with the free edition (no backups, only one database, lots of limitations).

The second error was that none of us had production level experience with Neo4J apart from what you just said, tinkering in toy projects at home or very low stakes services, so in the end, the schema that was created was a bit of a mess, you would look at it and say "well, it makes sense..." but in reality we were treating Neo4J as a twisted NoSQL/SQL interpretation.

The third mistake was treating Neo4J as a database meant to handle realtime requests from thousands of users doing filtering and depending on huge responses from external systems (VERY OLD systems, we're talking IBM AS400 old) while in an environment where each response depended on at least 2 or 3 microservices. We had one cypher query to handle almost all use cases, you can imagine what a behemoth that was.

In the end as I said, compound error between lack of experience, not analyzing correctly our needs and a "just go with it attitude" that to this day I'm pretty sure it cost quite a bit to the company. Eventually the backend team managed to move to MySQL (by that time I had moved to Ops) and the difference was abysmal.

[tunesmith]

Coincidentally, I've been toying with using concludia to make the argument behind a tech design for an upcoming project... when one of our teams is enamored with graph database for it - probably neptune in our case. So far I'm having trouble really nailing down the argument that would justify it.

[oscarcp]

I'd warn on the side of caution, moving from SQL to Graph is easier than undoing graph nodes, relationships and properties into a coherent SQL schema. Tread carefully :)