Atomicity: either all parts of the transaction complete, or all parts of the transaction don’t complete; there’s no “partly complete” state
Consistency: the state of the database after a transaction is stable; all “downstream” effects (e.g. triggers) of the query are complete before the transaction is confirmed.
Isolation: concurrent transactions behave the same as sequential transactions
Durability: a power failure or crash won’t lose any transactions
Traditionally, ACID is where relational databases shine.
ACID is really just an arbitrary set of requirements for databases that made sense way back in the day when things were much simpler. ACID starts to hold you back when you want to scale out, because to have consistency you have to wait for your transaction to percolate through all the nodes of your system, and it doesn’t allow for things like a replicating node to be temporarily offline or lagging behind. Turns out though that not everything needs to be strictly ACID. For example, there are many cases where it doesn’t matter that a reader node has stale data for a second or two.
The thing MongoDB does is that instead of being dogmatically ACID all the time it allows you to decide exactly how ACID your transactions and your reads need to be, through the writeConcern and readConcern parameters. If you want it to be completely ACID, you can, but it comes at a cost.
Traditionally, ACID is where relational databases shine.
Relational databases shine with ACID on single-node systems when they’re not trying to solve the scale-out problem that MongoDB is trying to solve, but when they are trying to do that, they actually do much worse.
For example: most RDBMS systems have some kind of replication system, where you can replicate your transactions to one or more backup nodes either for failover or to use as a read-only node.
Now if you consider that whole system, replicas included, as “the database”, none of them are ACID, and I don’t know of any RDMBS-es that has mechanisms to automatically recover from a crashed primary without data loss, or that can handle the “split brain” problem.
Atomicity: either all parts of the transaction complete, or all parts of the transaction don’t complete; there’s no “partly complete” state
Consistency: the state of the database after a transaction is stable; all “downstream” effects (e.g. triggers) of the query are complete before the transaction is confirmed.
Isolation: concurrent transactions behave the same as sequential transactions
Durability: a power failure or crash won’t lose any transactions
Traditionally, ACID is where relational databases shine.
ACID is really just an arbitrary set of requirements for databases that made sense way back in the day when things were much simpler. ACID starts to hold you back when you want to scale out, because to have consistency you have to wait for your transaction to percolate through all the nodes of your system, and it doesn’t allow for things like a replicating node to be temporarily offline or lagging behind. Turns out though that not everything needs to be strictly ACID. For example, there are many cases where it doesn’t matter that a reader node has stale data for a second or two.
The thing MongoDB does is that instead of being dogmatically ACID all the time it allows you to decide exactly how ACID your transactions and your reads need to be, through the
writeConcernandreadConcernparameters. If you want it to be completely ACID, you can, but it comes at a cost.Relational databases shine with ACID on single-node systems when they’re not trying to solve the scale-out problem that MongoDB is trying to solve, but when they are trying to do that, they actually do much worse.
For example: most RDBMS systems have some kind of replication system, where you can replicate your transactions to one or more backup nodes either for failover or to use as a read-only node.
Now if you consider that whole system, replicas included, as “the database”, none of them are ACID, and I don’t know of any RDMBS-es that has mechanisms to automatically recover from a crashed primary without data loss, or that can handle the “split brain” problem.