Transactions

In a database, a transaction is a sequence of operations performed as a single unit of work. For example, if you transfer money between accounts, both the debit and credit operations must succeed, or neither should occur.

In Fauna, every query is an ACID-compliant transaction, even across globally distributed Region Groups.

ACID properties

Database transactions follow ACID properties to ensure data integrity:

  • Atomicity: All operations in a transaction must be completed successfully or fail entirely.

    If some operations succeed while others fail, the successes are rolled back before being committed. There is no partial success.

  • Consistency: A transaction can only bring the database from one valid state to another valid state.

  • Isolation: Concurrent transactions should not affect each other. The isolation level determines how transaction integrity is maintained.

  • Durability: Once a transaction is committed, it remains committed.

Isolation levels

An isolation level refers to how a database maintains the integrity of its transactions. When a transaction is processed, the isolation level determines whether or how the transaction might be affected by other concurrent database operations.

Fauna transactions support three different isolation levels:

Serializability

Serialization guarantees that concurrent transactions produce the same result as if they ran one after another.

With serialization, developers don’t need to reason about concurrency. If each transaction is correct in isolation, they’ll be correct when run together.

For example, If two users simultaneously update their profiles, serializability ensures both updates complete correctly, as if one happened after the other.

Strict Serializability

Strict serialization, also called linearization, combines serializability with real-time ordering guarantees.

For example, if transaction A completes before transaction B begins, A’s effects are always visible to B. This is crucial for scenarios requiring strict ordering, such as implementing a reservation system where the first request should always win.

Strict serialization is the highest isolation available.

Snapshot isolation

Fauna indexes maintain a virtual snapshot of indexed documents. You can think of these snapshots as a "photograph" of the database at a specific time.

When you query a Fauna index without strict serialization, each transaction works with its own consistent snapshot of the data. This prevents "dirty" or non-repeatable reads.

Snapshot isolation works best for scenarios where you need a consistent view of the data but don’t require strict ordering guarantees, such as generating analytics reports.

Isolation levels in practice

The following table summarizes isolation levels available in Fauna based on a transaction’s operation types:

Index reads Read-write Read-only

None (documents only)

Strict serializability

Serializable

Only serialized or unique indexes

Strict serializability

Serializable

Indexes without serialization

Snapshot isolation

Snapshot isolation

Read-write transactions

Read-write (or write-only) transactions are always strictly serialized and don’t require additional configuration.

Read-only transactions

By default, read-only transactions are serializable for reads that don’t involve indexes. This provides strong consistency without requiring strict ordering guarantees.

To opt-in to strict serializability for read-only transactions, you can use either of these methods:

  • Include an X-Linearized header set to true for the transaction’s Query API request.

  • Include a no-op write in the transaction.

Driver configuration

The Fauna client drivers include configuration options for the X-Linearized header:

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!