Skip to main content
Learn

Transactions

Group multiple write operations into an atomic unit — all succeed together or all roll back together.

Transactions work the same way on RushDB Cloud and on a self-hosted engine: the engine stages each write and applies them all at commit. Until then, nobody sees them, and reads in the transaction see the committed data. Records are named by id, and the engine resolves each id inside the transaction, so you can update, delete and link records created earlier in the same transaction.

Basic Pattern​

The idiomatic approach uses the context manager — auto-commits on success, auto-rolls back on exception:

# Context manager (recommended)
with db.tx.begin() as tx:
    leo = db.records.create(label="ACTOR", data={"name": "Leonardo DiCaprio"}, transaction=tx)
    inception = db.records.create(label="MOVIE", data={"title": "Inception"}, transaction=tx)
    db.records.attach(source=leo, target=inception, options={"type": "ACTED_IN"}, transaction=tx)
# committed automatically — no explicit commit() needed

Or manually for more control:

tx = db.tx.begin()
try:
    movie = db.records.create(label="MOVIE", data={"title": "Inception"}, transaction=tx)
    actor = db.records.create(label="ACTOR", data={"name": "Leonardo DiCaprio"}, transaction=tx)
    db.records.attach(source=movie, target=actor, options={"type": "STARS_IN"}, transaction=tx)
    tx.commit()
except Exception:
    tx.rollback()
    raise

API Reference​

MethodDescription
db.tx.begin(ttl?) as ctx mgrStart transaction, auto-commit/rollback on scope exit
db.tx.begin(ttl?)Start a new transaction; returns a Transaction object
tx.commit()Persist all operations
tx.rollback()Discard all operations

Timeouts​

Uncommitted transactions are automatically rolled back after the TTL expires.

ParameterRushDB CloudSelf-hosted engine
Default TTL5 000 mstransactions.default-ttl-seconds (60 s)
Maximum TTL55 000 mstransactions.max-age-seconds (60 s); a larger ttl is capped

autocommit: true commits a transaction whose TTL elapses instead of discarding it.

tx = db.tx.begin(ttl=15000)   # 15 s timeout

Supported Operations​

CategoryStaged in a transaction
Recordscreate · update · set · delete_by_id / deleteById
Relationshipsattach
Importsimport_json / importJson · import_csv / importCsv (they report counts, not records, until commit)

These writes are refused inside a transaction, because the engine cannot stage them: deleting records by query (delete), detach, relationships.createMany / deleteMany, upserts and merge imports, writes with inline vectors, and property deletes. RushDB Cloud answers them with 400 Bad Request and rolls the transaction back; in direct mode the SDK throws DirectModeError before sending anything. Run them outside the transaction.

Reads (find, findById, …) see committed data, not the transaction's staged writes. A staged write returns its record as the transaction sees it.

A commit can fail with a conflict when another commit changed a record this transaction wrote; RushDB Cloud returns 409 Conflict. Begin a new transaction and retry. See Transactions in the engine manual for isolation and retry details.

See also​