I once joined a team which used RavenDB and literally the highest priority work which they were working on at that time was migrating completely off RavenDB because they had lost all confidence in it.
I had never heard of it until today, but a quick Google tells you it’s a Mongo-like JSON database with multi master capabilities. If you really really want those (I’m not sure it’s a good idea), then this seems way better than PG.
If you're not interested in a science experiment, Cassandra (or Scylla) are the multi-master databases that are mainstream and proven to work and scale. They're not fun or sexy and their feature set is much smaller but they do what they say and they work. Or AWS/GCP/Azure will happily give you an API for one.
It’s funny you say this when they’ve both failed jepsen tests. And by fail, I mean there are scenarios where they do not behave as intended - this is not to suggest either are broken inherently.
For sure. Virtually every Jepsen test has found bugs even with extremely mature products like Postgres. But fundamentally Cassandra (and Scylla) and most other databases tested have fixed those bugs and improved their documentation with many incorporating Jepsen tests into their ongoing process.
That's different from how Raven has just wildly mistated their capabilities.
That database spent 3-4 years primarily focused on correctness from 2018-2022.
The industry moves fast, our memories are slow. But there are millions of instances of cassandra in production across most of the fortune 500, and half of this thread has never heard of RavenDB
"Failed Jepsen tests" is relative; Kyle tends to be quite thorough in his Jepsen tests, so can usually find some issue in even the best of databases.
The big difference is in how severe the difference between claims and reality are, and how the maintainers or vendors react to such bug reports.
In some cases, the maintainers or vendors will fix bugs, or update docs to be more clear. The different transaction isolated levels are complicated and nuanced, and there are standards which disagree with the general consensus in the literature, so there can easily be ambiguities that need to be cleared up or bugs that need to be fixed.
But then there are things like RavenDB; where they make clearly impossible claims like "ACID across multiple documents and multiple cluster nodes in an AP database." There is simply no way to achieve this.
And then there's how they respond to his findings. He filed bugs and had had responses a month ago, about things like "this thing that is documented to have transactional semantics does not have transactional semantics", and their response was just to say "oh, yeah, that's expected", and not fix anything or update any of their documentation to reflect that.
So, there's a big gulf between "this is a complex topic, and even some of the best systems have some issues if you test it thoroughly enough", and "the documentation is blatantly lying about transactions and consistency, and the CEO of the company doesn't think it's a problem."
The batched operations that are sent in the SaveChanges()
will complete transactionally. In other words, either all
changes are saved as a Single Atomic Transaction or none
of them are. So once SaveChanges returns successfully, it
is guaranteed that all changes are persisted to the database.
But the tests in this post show that no, there is no single atomic transaction for a session saved with SaveChanges, even in a single node database this will lose writes.
I dunno. If I paid for an ACID database, I'd expect, well, some ACID features, like the ability to run two transactions concurrently and have them be isolated. It looks like RavenDB is fundamentally not implementing even the most basic of its claims. This isn't some "oh, yeah, this is a complex problem, and there are a few bugs lurking in obscure corner cases", this is "it fundamentally doesn't support what they claim to support as the major front-page selling point."
Their front page selling point is "Fully transactional NoSQL database" which links to a page that says "A database without transactions is… well, not much of a database, and as far as transactions are concerned – ACID is the gold standard."
But then in response to these findings, they say that the thing that is documented to have transactional semantics doesn't actually have transactional semantics.
Ravendb has an interesting use case. It's basically as easy to use as mongo DB, similarly scalable and at the same time is acid, has a nicer query language and is more secure.
Iike it actually more than SQL, especially for typical LOb apps.
