Comment by oscarcp
15 days ago
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.
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.
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 :)