ACID transactions

Keep multi-step writes consistent.

Transactions group related operations into one atomic unit. Either the complete workflow commits or none of its writes persist.

Start free View docs

Partial writes make connected workflows difficult to trust.

Creating records and relationships across several calls can leave half-finished state when a later step fails. Cleanup logic is easy to miss and difficult to test exhaustively.

Before

Write records one request at a time
Attach relationships after records exist
Handle cleanup manually after failures
Risk partially written agent state

With RushDB

Begin one transaction with a TTL
Pass it through related operations
Commit only after the complete workflow succeeds
Roll back explicitly or automatically on timeout

What it enables

Keep graph memory trustworthy under failure.

Agent workflows often create several records and relationships in one logical step. Transactions keep that step atomic so downstream agents do not read half-written context.

All-or-nothing graph writes

Create records, attach relationships, and update status inside one transaction that commits only when the workflow succeeds.

Safer concurrent work

Use transactions when multiple users, agents, or workers can touch the same connected records.

TTL-backed cleanup

Transactions have a time-to-live guardrail, so abandoned work rolls back instead of staying open indefinitely.

How it works

Start with the smallest useful path.

Begin a short transaction

Start a transaction with an appropriate TTL before the multi-step operation begins.

Perform related operations

Create records and relationships against the same transaction so they remain one unit of work.

Commit or roll back

Commit on success. Roll back in the error path instead of leaving partially completed graph state behind.

Flow

Atomic workflow lifecycle

The transaction lifecycle in the docs is simple: begin, perform related operations, commit on success, roll back on failure or timeout.

Begin transaction

Create records

Attach links

Commit success

Rollback failure

Implementation sketch

Commit related writes together.

Keep transactions short and always handle rollback. Transactions also roll back automatically when their TTL expires.

Know the operational boundary.

Built on Neo4j guarantees

RushDB transactions use Neo4j transaction capabilities for atomicity, consistency, isolation, and durability.

Read the transactions guide

TTL is a guardrail

Open transactions consume resources. Use explicit termination and keep operations short instead of relying on timeout cleanup.

Read about transaction TTL