Jepsen is an important sanity check on marketing. Easy to say in collateral you are "strict" ACID -- Jepsen proves (or denies) those claims. Some fun reports over there http://jepsen.io/analyses
A bit more precisely: Jepsen denies or doesn't a small subset of those claims.
It can't prove strict acid because it only observes behaviour it can observe. There are code paths it won't see in practice, so the best it can do is refute.
It also can't refute acid as a whole. If you look at the reports, they usually check the very basic behaviour - simple sets and gets. While that can tell you a lot about the system, you can't say it will generalise to complicated joins, multi-row operations, backend plugins, etc.
I would also say "strict" ACID is become just another marketing term. I think what is more important is evaluating a databases support of different consistency and isolation levels. As well what level of availability do they support with these transaction guarantees? Do they support fail over to an active replica on the fly with no downtime? Are minority replicas available during network partition?
"strict" ACID can mean a lot of different things. There is a lot of levels of consistency and they prevent different types of issues with data correction and isolation. I think database vendors should clarify what consistency model they mean as defined by https://jepsen.io/consistency
That's a great resource. We've tried to be consistent in using these terms. I think a lot of the confusion and lack of standardization over terminology came from the fact that database and distributed systems research had less overlap in the past...
Consistency in the ACID sense meaning something different from CAP Consistency is another good example.
Another point that often gets lost when talking about ACID guarantees is the maximum scope of a transaction that a system supports. There are many systems which support ACID guarantees for a single record or shard, but fewer that can support fully distributed transactions across a sharded dataset in a scalable manner.
It can't prove strict acid because it only observes behaviour it can observe. There are code paths it won't see in practice, so the best it can do is refute.
It also can't refute acid as a whole. If you look at the reports, they usually check the very basic behaviour - simple sets and gets. While that can tell you a lot about the system, you can't say it will generalise to complicated joins, multi-row operations, backend plugins, etc.