Check out v4 of the Fauna CLI
v4 of the Fauna CLI is now in beta. The new version introduces enhancements to the developer experience, including an improved authentication workflow. To get started, check out the CLI v4 quick start. |
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 totrue
for the transaction’s Query API request. -
Include a no-op write in the transaction.
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!