ACID & Transactions

TigerGraph provides full ACID (Atomicity, Consistency, Isolation, Durability) support with Strong Consistency, ensuring that your graph data remains reliable even under heavy write loads.

1. Transaction Definition

In TigerGraph, a transaction is a sequence of operations acting as a single logical unit.

• Each GSQL Query is a transaction.
• Each REST++ Operation (GET, POST, DELETE) is a transaction.

2. The ACID Pillars

Atomicity

Update operations (inserts, deletes, attribute changes) are "all or nothing." If a query attempts to update 10,000 vertices and fails on the last one, the entire operation is rolled back.

Consistency

TigerGraph provides Strong Consistency. An update is only considered complete once every replica in the cluster has finished the update. All replicas perform updates in the same strict order.

Isolation

TigerGraph uses Multi-Version Concurrency Control (MVCC) to support Read-Committed isolation. This ensures that readers never block writers and vice versa, while maintaining a consistent view of the data.

Durability

Committed transactions are written to disk (SSD/HDD). TigerGraph uses Write-Ahead Logging (WAL) to ensure that data can be recovered in the event of a system crash.

3. Transaction Thresholds

To prevent a single massive transaction from crashing the system, TigerGraph uses memory and size limits:

• Memory Limit: If a transaction exceeds a threshold (default 4MB), it is paged from memory to disk to save RAM.
• Size Limit: If a transaction is excessively large (configurable, default dynamic), it will be aborted to protect system stability.

[!TIP] You can adjust these limits using gadmin config set GPE.BasicConfig.Env.