Scalable Human Blog

The safety guarantees provided by transactions are often described by the well known acronym ACID.

What does ACID stand for?

• Anomicity
• Consistency
• Isolation
• Durability

Where does it come from?

In 1983 both Andreas Reuter and Theo Härder, outlined these properties to create clarification for what a fault tolerance mechanism is for databases.

The truth of ACID properties…

When comparing one database implementation of ACID with another, this does not directly mean they are the same…

For example, there is ambiguity around the the definition of Isolation. The high level idea maybe obvious, although with a microscope there are fundamental details to differentiate this.

Typically in todays systems, when there is a claim of being ACID “compliant”, it is unclear what guarantees you can expect… ACID has unfortunately become mostly a marketing term. 🤷‍♂️

Systems that do not meet the ACID criteria?

These are typically labelled BASE, which stands for:

• Basically
• Available
• Soft state
• Eventual consistency

This is even more vague than the definition ACID… 🤣

It seems the only sensible definition of BASE is… “not ACID“. That means it can be almost anything you want.

In the posts coming up, I will be exploring the definitions of Atomicity, Consistency, Isolation and Durability more, to carve out a more refined view of transactions. Thanks for reading.

📚 Further Reading & Related Topics

If you’re exploring ACID properties in databases and their impact on consistency and transactions, these related articles will provide deeper insights:

• Distributed Databases: Is Performance, Scalability, and Transactional Guarantees Achievable? – Learn how distributed systems balance ACID compliance with scalability and performance.

• Distributed Data-Intensive Systems: Reading and Writing Quorums – Understand how quorum-based approaches impact consistency, availability, and transactional integrity in distributed databases.