ACID vs BASE: Comparison of two Design Philosophies

The database you choose answers one question: how much of your data's correctness is the database's job, and how much is yours? This choice is usually hidden behind two fundamental data concepts: ACID and BASE.

In the "dark ages" of the early internet — somewhere around the turn of the millennium — the question of "which architecture to choose" usually boiled down to "which database to choose". The system was based on a relational DBMS: it stored data and ensured its consistency. As the service grew, engineers tried to push more and more load through it, but hit the same wall: the transactional guarantees that made the relational model great were exactly what made it hard to spread across many machines.

At the heart of this tradeoff are transactions — primarily ACID-compliant transactions.

This is a set of four properties required for reliable transaction processing:

• Atomicity
• Consistency
• Isolation
• Durability

Together, they ensure that a transaction is fully and correctly executed — without partial changes or data corruption — even in the event of a system failure. Let's go through them one by one.

This property ensures that a transaction is treated as a single, indivisible unit. All operations within a transaction must either complete successfully or fail completely. If any operation fails, the system rolls back the entire transaction, preventing partial data modifications.

For example in banking system atomicity ensures that funds are either debited from one account and credited to another, or the entire transaction is reversed (if an error occurs at any stage).

How is this property ensured?

The thing is, when a transaction — say, 10 INSERTs — enters the database, the data doesn't start changing immediately. Before the changes are applied, the transaction is written to a log, which records all the changes made. This same log can be used for data replication. Thanks to it, a transaction can either be committed directly to the data or, if necessary, rolled back.

The word "consistency" is overused in many contexts, causing people to get confused by the version of the same word from the CAP theorem.

In this context, consistency means something specific: a transaction can only generate valid data. This property ensures that a transaction transitions the database from one valid state to another, and after the transaction completes, the data must satisfy all integrity checks.

This property prevents concurrent transactions from interfering with each other. Even under high load, parallel transactions should not interfere with each other's results — each transaction is executed as if it were the only one in the system.

Without this property, rollback would be impossible — and thus atomicity itself: somehow, something would have to be "undone" that had already been processed and executed by another transaction.

For example, if two customers attempt to purchase the last item at the same time, isolation ensures that only one transaction will be successful and inventory levels will be updated correctly.

The cost of transactionality often goes down to the cost of providing isolation; that's why isolation has different levels, each providing its own level of protection against race conditions (check out details in "Grokking Concurrency") and incurring certain overhead. Complete isolation is guaranteed only at the serializability level, which is very difficult to implement and honestly rarely required.

Durability ensures that the results of a completed transaction are preserved forever (sic!). The result must withstand all subsequent events: crashes, reboots, data center power outages, meteor showers, and alien invasions. If it's committed, it's committed.

Durability is also a somewhat marketing term, as it cannot be fully guaranteed.

Even if we dismiss the scenarios of "alien invasions of the Earth" after which no databases or transactions remain, and the more probable but extreme scenarios of the physical destruction of the specific hard drive on which the transaction was committed, we can remember that the fsync system call guarantees a hit to the hard drive controller, which, in turn, contains a volatile buffer. The dwell time in this buffer is short, but not zero. Hence, even if the power is turned off at the right moment, the transaction may still be lost!

Nothing can protect us from problems associated with the physical destruction of a machine. We can only increase the guarantees by using backups and replication.

As data volumes and availability requirements grew, the approach to database design also evolved. To scale horizontally and maintain high availability, engineers began moving database logic to separate servers, leaving the database with a sole task: data storage.

This step means abandoning almost all ACID consistency guarantees. Consistency here again means something different: it refers to what happens when multiple nodes maintain their own copies of data. Reading from two different nodes will yield two different results, since each node can update its own copy independently. Conflicts happen, but nodes swap changes, and eventually converge to a single value.

This is the world of NoSQL, where ACID's guarantees are overkill for what most tasks need. NoSQL trades them for a different model — BASE:

• Basic Availability
• Soft state
• Eventual consistency

The system remains available even if some data is inconsistent or unavailable. This is achieved by distributing data across multiple nodes with dense replication rather than using a single, large, fault-tolerant data store. Losing a partition typically results in the loss of only a portion of the database, not the entire database.

Unlike a traditional system, where data stays exactly as written until someone changes it, a BASE system's state can drift on its own — even with no new writes — as replicas sync up in the background.

A hard-state system is like a light switch: flip it on, and it stays on until someone flips it off. A soft-state system is more like a group chat catching up on messages after being offline — the final state settles on its own, without anyone touching it directly.

The only promise is that the data will eventually reach a consistent state. When exactly this will happen is not guaranteed.

In contrast — with ACID is what happens the moment after a commit. There, once the transaction returns, the next read sees it. Here it might not, and nothing tells you which case you are in.

BASE exists primarily due to the laws of physics: if a record is copied across three regions, the signal propagation speed will reach the speed of light before any database engine can process it. Physically, a node in São Paulo cannot know about a record in Frankfurt before the packet reaches it. Eventual consistency is not so much a design decision as an acknowledgement of limitations — of what the network allows in principle.

At its core, BASE is a mirror image of ACID: it asserts that true consistency in the ACID sense becomes increasingly difficult to guarantee as a system becomes more distributed — not impossible, but simply a different and much more expensive promise to make:

1. ACID ensures strong consistency after each transaction, strictly enforcing integrity rules. BASE sacrifices strong consistency for performance and availability — data may be temporarily inconsistent, but will be restored later.
2. ACID systems prioritize consistency, which can make them unavailable during failures. BASE systems focus on high availability and remain responsive even during network problems or individual node failures.
3. ACID systems have difficulty scaling horizontally because strict consistency on distributed systems requires significant resources. BASE systems scale easily and are designed for distributed architectures, where temporary inconsistencies are tolerated.

It all depends on your project and the nature of the problem — as with almost everything in engineering. If an approximate answer is acceptable and the user truly cares about speed, BASE is the best tool. If the opposite is true, ACID provides a data system you can trust without constant re-checking.

Most large systems today, including cloud-based ones, use a combination of both models rather than a single solution for the entire stack.

NewSQL databases like Spanner and CockroachDB strive to simultaneously provide both sets of guarantees: ACID correctness of the relational model and horizontal scalability with capabilities previously available only to BASE. Spanner achieves this with TrueTime: GPS and atomic clocks in each data center synchronize time across regions with sufficient precision to guarantee strict serializability. CockroachDB achieves the same goal with Raft and hybrid logical clocks, without the need for specialized hardware.

But you can't fool physics — the speed of light that powers BASE hasn't disappeared. A transaction spanning multiple regions still must wait for confirmation from nodes in other regions before committing. Spanner demonstrates this quite literally: it deliberately waits ("commit wait") until the maximum time uncertainty window has passed, and only then commits the transaction. NewSQL doesn't eliminate the tradeoffs; it simply shifts them: instead of stale data on the client side, you pay with inter-region write latency and infrastructure complexity. There's still no free lunch — it's just hidden one level lower.

To be honest BASE is more of a marketing thing to me than a technical concept. It offers nothing new and doesn't really define the database itself — the name just confuses those just starting out.

I'm still learning these terms, because they're unavoidable if you're seriously studying databases. Now that you know what they mean, you can safely forget the acronym and remember the tradeoff itself.