I've been thinking about ACID recently. ACID describes how transactions should behave in databases. It means: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.
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:
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.