Formalizing ACID in Lean 4: The Durability Illusion

In this exploration, we examine a programmer's attempt to formalize the ACID properties using Lean 4. The exercise revealed unexpected insights, particularly about durability, leading to a deeper understanding of modeling boundaries. Below, we answer key questions about the approach and its findings.

What was the goal of formalizing ACID in Lean 4?

The author sought to ask a fundamental question: What kind of structure is ACID preserving? Instead of taking ACID definitions at face value, they aimed to represent the core concepts (Atomicity, Consistency, Isolation, Durability) in a minimal, formal model using Lean 4. The goal was not to prove that real databases are correct, but to explore what assumptions are necessary for each property. By stripping away operational details like logs, crashes, and concurrency control, they hoped to reveal the essential structural requirements. The exercise was a deliberate simplification: keep the state-transformer shape, drop everything else. The result was not a proof of database correctness but a reminder that every design claim depends on what the model can actually observe.

How did the author define Consistency in their model?

Consistency was reinterpreted as invariant preservation. In the model, there is a state space S and an invariant predicate inv : S → Prop that defines which states are valid. A transaction is an operation on the state, and for consistency to hold, every transaction must map a valid state to another valid state. This is a purely static property: if the invariant holds before a transaction, it must hold after. The author did not model constraints like foreign keys or triggers; instead, they focused on the shape of consistency as a property that must be preserved across all allowed transitions. This formalization is deliberately abstract, applicable to any system where you can define a state space and an invariant.

How did the author define Isolation in their model?

Isolation was defined as a deliberately strong commutation law. In the minimal model, histories are represented as lists of transactions. The replay function composes these transactions in order. For isolation, the author required that the result of composing a history is equivalent to some serial order of the transactions. In other words, the effect of concurrent execution (not explicitly modeled) is the same as if transactions were run one after another in some order. This is a commutation property: the composition of two transactions should give the same result regardless of their order if they commute. The author noted that real DB isolation levels are weaker, but here they aimed for a clean, provable property. This approach highlights that isolation is fundamentally about reordering operations without changing the overall outcome.

Why was Durability suspiciously easy to prove?

The suspicious part was not that Lean failed to prove durability, but that it proved it with almost no assumptions. In the author's model, there is no concept of system crash, power loss, or non-volatile storage. Durability simply means: after a transaction commits, its effects persist. But since the model has no persistence boundary—no distinction between memory and disk, no failure modes—the proof is trivial. The model can always apply the transaction and the state remains changed. This exposed that the formalization had no way to model durability failures. The author realized that a genuine durability property must include a notion of what it means for effects to survive after the system loses volatile state. Without modeling crashes, durability is just an identity statement. This insight was the key lesson: one must carefully choose what is visible in the model, otherwise properties become vacuously true.

What is the minimal model they used?

The model is defined in Lean 4 with three components: a state space S, a set of transaction types Txn, an apply function apply : Txn → Endo S (where Endo S is a function from S to S), and an invariant inv : S → Prop. This is extremely abstract: S could represent a relational database, an event-sourced aggregate, or any stateful system. The author intentionally avoided operational details like concurrency, logging, or crashes. The point was to see what could already be said just from the shape: each transaction is a state transformer, and the invariant is a predicate on valid states. This minimal model is a projection of real ACID, losing many details but retaining the structural essence. It allows one to ask: what properties are inherent to this shape, and what properties require extra assumptions?

What does the history replay function represent?

The function Model.replay takes a list of transactions and returns a composite endomorphism on the state space. The base case for an empty list is the identity function (no change). For a non-empty list, it recursively applies each transaction in order. This represents the composition of a sequence of operations—essentially the sequential execution of a history. The author used this to reason about consistency and isolation: a consistent history preserves the invariant at each step, and serializability means the final state is reachable by some ordering of the transactions. The function is purely functional and deterministic, which is a simplification of real-world concurrency. However, it serves as a clean foundation for proving properties about transaction sequences. The replay function is the core of the model's ability to express notions of sequential equivalence.

What lesson did the author learn about design claims?

The author learned that every design claim depends on what the model can actually see. The durability property was trivially provable because the model omitted the concept of failure. This is a cautionary tale: when you formalize a system, you must be explicit about what is included and what is abstracted away. If a property becomes too easy to prove, it might be because you left out the very thing that makes it non-trivial. In real databases, durability is hard because it involves persisting to durable media, handling crashes, and ensuring recovery. The author's minimal model made durability vanish into a tautology. This insight applies broadly: any formal model is a lens that focuses on certain aspects and ignores others. The claims you can prove are only as strong as the model's boundary.