0% completed
ACID vs BASE Properties in Databases
On This Page
ACID
BASE
One Word, Two Meanings
CAP Underneath
The Difference That Matters
Transfer money and the system fails halfway. The bank took 100 from your account and never added it to the recipient's. Nobody accepts that from a bank.
Databases have two famous answers to this danger, and they pull in opposite directions.
ACID keeps every transaction strictly correct, even if the system must pause or refuse work to do it. BASE keeps the system answering, even if some answers are briefly out of date.
This lesson explains both. It also clears up the one confusion that costs candidates points: the word consistency means a different thing in each.
ACID
A transaction is a unit of work with several steps that must count as one. Transferring money is the standard example. Step one takes 100 from account A. Step two adds 100 to account B.
ACID names four promises a database makes about transactions: Atomicity, Consistency, Isolation, and Durability.
Atomicity: all or nothing. The transaction happens completely, or not at all. If step two fails, step one is undone. Money is never taken without being delivered.
Consistency: the rules always hold. Every database has rules about its data. A balance may not go below zero. Every order must belong to a customer. Consistency means each transaction moves the data from one state that obeys the rules to another state that obeys them. In the transfer, the total across both accounts is the same before and after.
Isolation: transactions do not disturb each other. Transactions running at the same time behave as if they ran one after another. A reader sees a stock count before an update or after it, never a half-updated value in between.
Durability: committed means saved. Once the database confirms the transaction, the change survives a crash or a power failure. If a messaging app says your message was sent, it is stored, even if the server dies a moment later.
Relational databases such as MySQL and PostgreSQL are built around these promises.
The promises have a cost. Keeping them means locking and waiting, and across several machines it means a lot of coordination. That cost is what BASE removes.
BASE
BASE describes how many NoSQL and distributed stores behave. It stands for Basically Available, Soft state, Eventually consistent.
Basically Available: the system answers. Even during heavy load or a partial failure, it gives some response. The response may be slightly out of date. During a big sale, the store keeps taking orders while the inventory counts run a little behind.
Soft state: the data can change on its own. Updates spread between the copies in the background. So a copy can change without any new input, as older updates arrive at it.
Eventually consistent: the copies converge. Stop the writes, wait, and every copy ends up with the same value. There is no promise about how long that takes. Strong vs Eventual Consistency covers what that waiting means for readers.
One Word, Two Meanings
Here is the trap. The C in ACID and the C in CAP are not the same thing.
The C in ACID is about one database. It says every transaction leaves the data obeying its own rules. No negative balances. No order without a customer. A single machine can make this promise by itself.
The C in CAP is about many machines. It says every read returns the newest write, no matter which copy answers. This promise only means something when the data lives on more than one machine.
Same letter, different subjects. When someone says a BASE store "gives up consistency", they mean the CAP kind. Copies of the data may briefly disagree with each other. They do not mean the store corrupts data or forgets its rules.
CAP Underneath
The CAP theorem explains why the ACID and BASE styles both exist.
The theorem names Consistency, Availability, and Partition tolerance, and it is often quoted as "pick two of three". That wording misleads, because partition tolerance is not yours to pick. A partition is a network failure that cuts machines off from each other. Networks fail whether you plan for it or not.
So the real choice appears during the failure. While the machines cannot reach each other, a store does one of two things.
ACID-style systems refuse. The user sees an error or a wait, and never a wrong value. BASE-style systems answer. The user always gets a response, and it may be old.
That is the whole trade in one sentence, and it is why the two acronyms exist. The full argument is in CAP Theorem.
The Difference That Matters
| ACID | BASE | |
|---|---|---|
| Priority | Correctness | 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 store, copies can disagree, and someone must decide which value wins. That someone is your application. The work of resolving conflicts does not disappear when you choose BASE. It moves from the database into your code.
💡 In the interview: if you say "we will use BASE", expect the follow-up: what happens when two replicas disagree? Have a concrete answer, such as last write wins, a version vector, or a merge rule for that exact data. And keep the two meanings of consistency separate. BASE relaxes the CAP kind, which is agreement between copies. It does not mean the data stops following its rules. Mixing the two C's up is the kind of slip an interviewer hears at once.
Key takeaway: ACID is four promises about a transaction: all or nothing, the rules always hold, no interference, and committed means saved. BASE is a different bargain: the system always answers, updates spread in the background, and the copies converge in time. The C in ACID is one database obeying its rules, and the C in CAP is many machines agreeing on the newest value. Partitions are a fact, not a choice, so during one a store either refuses like ACID or answers with old data like BASE. And in a BASE store, resolving disagreement between copies is the application's job.
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.
knowledgeshop
· 6 days ago
There is major difference in what Consistentcy is in CAP theorem vs what is in ACID. In ACID we are talking about single transaction, rules and constraints in one single database and in CAP we are talking about nodes - about replicas agreeing, multiple machines (distributed systems). This should be corrected and informed.
On This Page
ACID
BASE
One Word, Two Meanings
CAP Underneath
The Difference That Matters