0% completed
ACID vs BASE Properties in Databases
On This Page
ACID
BASE
The Difference That Matters
CAP Underneath
Transfer money and something goes wrong halfway through. You would not accept the bank deducting from your account without adding to the recipient's. That expectation has a name, and databases take two different approaches to meeting it.
ACID is about keeping transactions strictly correct and reliable. BASE is about keeping the system basically available and scalable, even if the data is briefly inconsistent.
They read as opposites. Each has its place.
ACID
ACID is a set of properties guaranteeing that transactions are processed reliably. A transaction is a unit of work, such as transferring money or booking a ticket, that may involve several steps.
ACID stands for Atomicity, Consistency, Isolation, and Durability.
Atomicity: all or nothing. A transaction executes completely or not at all. In a reservation system, booking a seat and updating the customer's details must both succeed. If one part fails, the partial changes are undone, so you never end up with a seat reserved under no name.
Consistency: a valid state. The database obeys all its defined rules after the transaction, moving from one valid state to another. Transferring 100 from account A to account B, the total across both accounts is the same before and after.
Isolation: no interference. Several transactions running at once each behave as if they were the only one. If one user is updating a product's stock count, another user reading it sees either the old count or the new one, never something in between.
Durability: never lost. Once a transaction commits, its changes are permanent and survive power failures and crashes. If a messaging app says your message was sent, it is stored, even if the server dies a moment later.
BASE
BASE is the alternative used in many NoSQL and distributed databases. It stands for Basically Available, Soft state, Eventually consistent.
Rather than enforcing strict consistency after every transaction, BASE systems prioritize availability and partition tolerance. The system stays basically available at all times, and it accepts that the data may not be consistent immediately as long as it becomes consistent eventually.
Basically Available. The system will try to give you some response even under heavy load or partial failure. It may not be the most up to date data, but the service stays up. During a large online sale, a BASE-model store keeps accepting orders and showing products even if inventory counts are slightly behind.
Soft State. The state of the system may change over time even without new input, because updates propagate gradually. The data may be temporarily inconsistent and can keep changing as those updates spread. The database does not enforce immediate consistency itself.
Eventually consistent. Given enough time and no new updates, every copy converges on the same value. There is no promise about how long that takes.
The Difference That Matters
| ACID | BASE | |
|---|---|---|
| Priority | Consistency | Availability |
| After a write | Everyone sees it immediately | Everyone sees it eventually |
| During a partition | May refuse to answer | Answers with what it has |
| Who handles disagreement | The database | The application developers |
| Typical home | Relational databases | NoSQL and distributed stores |
The fourth row is the one people miss. In a BASE system, temporary inconsistencies are handled by the application developers, who have to reconcile conflicts, because the database does not guarantee that every copy is the same at once. That work does not disappear when you choose BASE. It moves.
CAP Underneath
The CAP theorem says a distributed data store can guarantee only two of three properties: Consistency, Availability, and Partition tolerance. The theorem itself, and why there is no genuine CA option once a store is actually distributed, is covered in CAP Theorem.
Partitions happen in any real distributed system, so the honest reading is that you are choosing between consistency and availability when one occurs. ACID systems favour consistency. BASE systems favour availability and accept eventual consistency.
That is the whole trade in one sentence, and it is why the two acronyms exist.
💡 If you say "we will use BASE," expect to be asked what happens when two replicas disagree. Having an answer, last-write-wins, a version vector, a merge rule for that specific data, is what separates knowing the acronym from having designed the system.
💡 In the interview: do not present this as a database feature list. Present it as a question about the data: does anything here have to be all-or-nothing? Money moving between accounts does, so that part gets ACID. A view counter does not, so it can live in a BASE store and nobody notices. Naming which parts of one system need which is a much stronger answer than picking an acronym for the whole design.
Key takeaway: ACID means Atomicity, Consistency, Isolation and Durability: transactions are all or nothing, leave the data valid, do not interfere with each other, and survive crashes. BASE means Basically Available, Soft state and Eventually consistent: the system always answers, the data may drift and keep changing as updates spread, and copies converge in time. Under CAP a distributed store can guarantee only two of consistency, availability and partition tolerance, and ACID picks consistency while BASE picks availability. In a BASE system, reconciling inconsistency becomes the application's job.
For the consistency side of this trade in more depth, see Strong vs Eventual Consistency earlier in this chapter.
Gerhard Matzen
· a year ago
The course text say:
In the CAP theorem, a distributed system can only guarantee two out of three: Consistency, Availability, Partition tolerance.
However, it seems to me that "partition tolerance" is not a choice. Partitions will happen in distributed systems. When they do, you can choose between consistency and availability.
On This Page
ACID
BASE
The Difference That Matters
CAP Underneath