FQL v4 will be decommissioned on June 30, 2025. Ensure that you complete your migration from FQL v4 to FQL v10 by that date.

For more details, see the v4 EOL announcement and migration guide. Contact support@fauna.com with any questions.

Isolation levels

Isolation levels refers to how a database maintains the integrity of transactions. When a transaction is being processed, the isolation level that is in effect determines whether, or how, the transaction might be affected by other concurrent database operations.

Fauna supports three isolation levels:

The following table summarizes Fauna’s consistency levels under different conditions:

Index Reads Read‑Write Read‑Only

None (documents only)

Strict Serializability


Only serialized or unique indexes

Strict Serializability


Non-serialized indexes

Snapshot Isolation

Snapshot Isolation

* Read-only transactions are, by default, serializable in Fauna for non-index reads. Reads can opt-in to strict serializability by using the linearized endpoint, or by including a no-op write in the transaction.


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.

Strict Serializability

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:

  1. the final state is equivalent to processing transactions in a serial order, and

  2. X must be before Y in that serial order.

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.

Is this article helpful? 

Tell Fauna how the article can be improved:
Visit Fauna's forums or email docs@fauna.com

Thank you for your feedback!