Isolation levels

Serializability guarantees that the execution of a set of transactions on multiple items is equivalent to some serial-ordered execution of those transactions. Serializability has been regarded as the gold standard of isolation. A system that guarantees serializability is able to process transactions concurrently, but guarantees that the final result is equivalent to having processed the transactions serially, one after the other with no concurrency. This is an incredibly powerful guarantee that has withstood the test of time, enabling robust and bug-free applications to be built on top of it.

What makes serializable isolation so powerful is that the application developer doesn’t have to reason about concurrency at all. The developer just has to focus on the correctness of individual transactions in isolation. As long as each individual transaction doesn’t violate the semantics of an application, the developer is ensured that running many of them concurrently will also not violate the semantics of the application.

Although serializability works fine in the context of a single database server, it is not as consistent as it seems when it comes to a distributed global database.

The first limitation of serializability is that it does not constrain how the equivalent serial order of transactions is picked. Given a set of concurrently executing transactions, the system guarantees that they will be processed equivalently to a serial order, but it doesn’t guarantee any particular serial order. As a result, two replicas that are given an identical set of concurrent transactions to process may end up in very different final states, because they chose to process the transactions in different equivalent serial orders. Therefore, replication of databases that guarantee "only" serializability cannot occur by simply replicating the input and having each replica process the input simultaneously. Instead, one replica must process the workload first, and a detailed set of state changes generated from that initial processing is replicated (thereby increasing the amount of data that must be sent over the network, and causing other replicas to lag behind the primary).

The second, but related, limitation of serializability is that the picked order of transactions doesn’t have to be at all related to the order of transactions that were submitted to the system. A transaction Y that was submitted after transaction X may be processed in an equivalent serial order with Y before X.

Strict serializability adds a simple extra constraint on top of serializability. If transaction Y starts after transaction X completes, which means that X and Y are not (by definition) concurrent, then a system that guarantees strict serializability guarantees that both:

For an application that applies transactions serially, these guarantees would seem obvious: when Y comes after X, X is before Y. However, strict serializability is particularly difficult to attain in distributed databases. In a typical distributed database, the factors influencing whether strict serializability can be maintained, or is even possible, include: replication strategy, clock drift, network jitter, variable CPU workloads, etc.

Fauna indexes maintain a virtual snapshot of participating documents. When an index is used in a transaction, the documents associated with the index are evaluated, guaranteeing isolation for read and write queries.

For an analysis of Fauna’s serializability performance, see the Jepsen report on Fauna from March 5, 2019, which validated that Fauna meets its expected isolation levels, and more.