Hi guys.
I'm contemplating whether or not I should plan an RDB alongside my GraphDB, for what I'd consider classic transactional data, such as billing.
The main DB in our solution, tracking learning paths of students, would be maintained in the GraphDB for sure.
I know that neo4j is ACID and I should not worry about "eventual consistent" anymore, but I'm still seeking reassurance as to how I can rely on that for the complete persistence, including accounts and billing.
Any reason you see why some DB should be still maintained in RDB?
I don't think you need to worry. In fact I think you'll find more issues trying to maintain two data stores rather than committing to one. This is a situation I think you either need to just take the plunge and go all in or not.
You already know that it's an ACID database but you're still looking for more reassurances. In which case I say the only person who is going to be able to convince you is yourself. Ask yourself this question, why do you trust a SQL database to do it's job? Is there a situation test you put your SQL DBA through before you trusted it? If so go ahead and put Neo4j through the same test.
Thanks Mike.
I guess when I started relying on RDBMS, it was already well established and proven. It had passed the test of time in many organizations and situations. The transaction concept was already ironed-out so I could rely on its proven history.
I still feel that ACID Graph DB are relatively new in this. How many mission-critical, large-scale production neo4j implementations are our there for couple of years+ relying on its ACID for billing and similar demands? I really don't know, hence my question.
I appreciate your take on it!
The first 5 mins of Emil's speech at the 2018 GraphConnect has some organizations that are using Neo4j today for mission critical applications GraphConnect 2018 Keynote: Emil Eifrem and Hilary Mason - YouTube
Or there's Jim Webber's video talking about Adobe's use of Neo4j Neo4j for Very Large Scale Systems - YouTube
And then you can familiarize yourself with the inner workings on Neo4j's transaction log. De-mystifying how something works, I find brings confidence in using it Transaction log - Operations Manual
Thanks Mike.
Unfortunately, none of these pointers offered reassurance as for mission-critical, ACID demanding implementations.
I know neo4j is scalable. I know it is used by many organizations. I don't know if any is relying on it for its hard-core transactions involving billing, reservations, ticketing and the like.
This is basically what I'm after.