blog‎ > ‎Geek corner‎ > ‎

The C in ACID

posted Jul 26, 2013, 3:45 AM by Max Tardiveau   [ updated Jul 26, 2013, 4:04 AM ]

What does it mean to be consistent?

I've been thinking about ACID recently. ACID describes how transactions should behave in databases. It means:
  • Atomic : everything in a transaction goes in, or nothing goes in, but nothing in-between
  • Consistent : more on that in a minute
  • Isolated: the user should have the illusion (as much as possible) that s/he is the only one using the database; other concurrent transactions should (ideally) not interfere.
  • Durable: whatever the transaction does, if it succeeds, should be permanent.

The A is what most programmers think of when they think of transactions. That's because most programmers have an appallingly limited knowledge of this stuff. Atomicity is important, obviously, but it's not the be-all and end-all of transactions, not by a long stretch.
The D is (rightfully) taken for granted by most people, so let's not worry about it.
The I is poorly understood by most programmers, but that's not relevant here, so let's ignore it.
The C is what I'd like us to think about, because it's always been a bit fuzzy.

What does it mean for data to be consistent? Consistent with what? So far, for almost all relational databases, it means that the data must conform to the schema:
  • data types must be respected -- e.g. no putting string in numbers
  • required columns can not be null
  • foreign keys must be valid
  • some very limited additional validation may be possible, depending on the database, e.g. age should be between 0 and 120, sex must be M, F or O, etc...

But that's about it1. If you want to go beyond that, you have to use triggers, stored procedures and similar mechanisms. Wikipedia says about consistency:

This does not guarantee correctness of the transaction in all ways the application programmer might have wanted (that is the responsibility of application-level code) but merely that any programming errors do not violate any defined rules.

And that's where the industry has been for the past 20 years: you take a database system, and you put a layer of code on top of it. It's difficult, it's expensive, and goodness help you if your logic changes.

That is the disconnect that Espresso Logic solves. We offer a solution that provides all the advantages of relational databases, but with a much higher level of declarative consistency. We make it possible to think about data at a higher level.

We can be the C in ACID. We can bring deep consistency to the database, not the superficial consistency that is still the standard today. And we can make it easy.

1 - Note that NoSQL databases don't even have most of these; they're even more of a free-for-all, which is fine for many applications, but hopelessly inadequate for many others.