Transactions

All Cypher queries are run within transactions, which means that all modification made by a single query are held in memory by the transaction until the query is successfully executed. The changes are then committed and visible to all other transactions, users and systems. In the case of an error, the transaction is rolled back and no changes are committed.

These automatic transactions are also called implicit transactions.

You can also create explicit transactions to execute multiple Cypher queries in sequence, then commit them or roll them back.

If you want to switch between storage modes, there can’t be any active transactions. Memgraph will log a warning message if it finds any active transactions, so set the log level to WARNING to see them. No other transactions will take place during the switch between modes.

During transaction execution, an important property of a database is the isolation level that defines how or when the changes made by one operation become visible to others.

Explicit transactions

To start a transaction, run the BEGIN; query.

All the following queries will be executed as a part of a single transaction.

If any of the queries fails during execution, further queries will no longer be successfully executed and it won’t be possible to commit the transaction. As active constraints are checked upon commit, multi-query transactions will be committed as long as the database adheres to the constraints upon the execution of the final query.

Commit successful transactions by executing the COMMIT; query.
Roll back unsuccessful transactions by executing the ROLLBACK; query.

Auth queries, such as CREATE USER and GRANT, can also run in an explicit transaction, but not in the same transaction as other queries. See Run auth queries in a transaction.

The following query will find to nodes and adjust a certain relationship property in order to check the results of a max_flow algorithm, then rollback the change as this query was a part of an what-if analysis:

BEGIN;
 
MATCH (e:E)-[r:CONNECTED_TO]->(f:F)
SET r.flow = 17;
 
MATCH (a:A), (f:F)
CALL max_flow.get_flow(a, f, "flow") YIELD max_flow
RETURN max_flow;
 
ROLLBACK;

Optimistic vs. pessimistic approaches

In database management systems, there are two approaches to handling potential conflicts. The optimistic approach checks for conflicts only during the commit. If a conflict occurs, the transaction is rolled back. On the other hand, the pessimistic approach entails making additional checks to prevent conflicts from occurring in the first place.

The difference between the two approaches is relevant in several areas of Memgraph’s operation: concurrency control and constraint checking.

In constraint checking, Memgraph takes the optimistic approach. Multi-query transactions will be committed as long as the database adheres to the constraints upon the execution of the final query in the transaction.

Manage transactions

Memgraph can return information about running transactions and allow you to terminate them.

Show transactions

To get information about all active transactions execute:

SHOW TRANSACTIONS;

Each row in the result represents one transaction (or an in-progress snapshot creation or garbage collection) and contains eight columns:

In the query column, a query that sets a password, such as CREATE USER with IDENTIFIED BY or SET PASSWORD, shows each password as '****'.

+----------+-----------------------+------------------------------------------------------+-----------+----------+----------------------------------------+------------+------------+
| username | transaction_id        | query                                                | status    | metadata | start_time                             | elapsed_ms | database   |
+----------+-----------------------+------------------------------------------------------+-----------+----------+----------------------------------------+------------+------------+
| ""       | "9223372036854775816" | ["SHOW TRANSACTIONS"]                                | "running" | {}       | 2026-10-12 12:13:47.209533000[Etc/UTC] | 0          | "memgraph" |
| ""       | "9223372036854775815" | ["UNWIND range(1, 100) AS i CREATE (:Item {id: i})"] | "running" | {}       | 2026-10-12 12:13:47.116640000[Etc/UTC] | 93         | "memgraph" |
+----------+-----------------------+------------------------------------------------------+-----------+----------+----------------------------------------+------------+------------+

Filter by status

You can limit the output to transactions in a specific lifecycle phase by naming one or more statuses before the TRANSACTIONS keyword:

SHOW RUNNING TRANSACTIONS;
SHOW COMMITTING TRANSACTIONS;
SHOW ABORTING TRANSACTIONS;
SHOW RUNNING, COMMITTING TRANSACTIONS;

When multiple statuses are listed (comma-separated) the result is their union — rows matching any of the requested statuses are returned. Omitting the status list is equivalent to requesting all three statuses.

Snapshot progress rows

While a snapshot is being created (triggered periodically, on exit, or manually with CREATE SNAPSHOT), a synthetic row is included in the result with transaction_id set to "snapshot". The metadata map for these rows contains:

The top-level start_time and elapsed_ms columns are populated for snapshot rows as well, reflecting when the snapshot started.

+----------+-----------------------+-----------------------+-----------+-----------------------------------------------------------------------------------+----------------------------------------+------------+------------+
| username | transaction_id        | query                 | status    | metadata                                                                          | start_time                             | elapsed_ms | database   |
+----------+-----------------------+-----------------------+-----------+-----------------------------------------------------------------------------------+----------------------------------------+------------+------------+
| ""       | "9223372036854775818" | ["SHOW TRANSACTIONS"] | "running" | {}                                                                                | 2026-10-12 12:13:47.275859000[Etc/UTC] | 0          | "memgraph" |
| ""       | "9223372036854775817" | ["CREATE SNAPSHOT"]   | "running" | {}                                                                                | 2026-10-12 12:13:47.221765000[Etc/UTC] | 54         | "memgraph" |
| ""       | "snapshot"            | ["CREATE SNAPSHOT"]   | "running" | {db_name: "memgraph", items_done: 53824, items_total: 3000100, phase: "vertices"} | 2026-10-12 12:13:47.221848000[Etc/UTC] | 55         | "memgraph" |
+----------+-----------------------+-----------------------+-----------+-----------------------------------------------------------------------------------+----------------------------------------+------------+------------+

Garbage collection rows

Storage garbage collection runs continuously in the background to reclaim obsolete object versions. While a collection is actively running, a synthetic row is included in the result with transaction_id set to "gc" and query set to ["GARBAGE COLLECTION"]. This makes a slow, stuck, or blocking collection directly observable; a healthy run finishes in well under a millisecond and is rarely caught. The metadata map for these rows contains:

The top-level start_time and elapsed_ms columns reflect when the collection started; a large elapsed_ms is the clearest signal of a stuck collection. One gc row appears per database that currently has a collection running.

For example, a FREE MEMORY query on the tenant1 database starts a forced collection. While that collection runs, run the following query from another session:

SHOW TRANSACTIONS;

The result lists the FREE MEMORY transaction and its gc row, both on tenant1:

+----------+-----------------------+------------------------+-----------+---------------------------------------------------------------------------------+----------------------------------------+------------+------------+
| username | transaction_id        | query                  | status    | metadata                                                                        | start_time                             | elapsed_ms | database   |
+----------+-----------------------+------------------------+-----------+---------------------------------------------------------------------------------+----------------------------------------+------------+------------+
| ""       | "9223372036854775814" | ["FREE MEMORY"]        | "running" | {}                                                                              | 2026-10-19 12:01:18.288170000[Etc/UTC] | 4          | "tenant1"  |
| ""       | "9223372036854775815" | ["SHOW TRANSACTIONS"]  | "running" | {}                                                                              | 2026-10-19 12:01:18.292917000[Etc/UTC] | 0          | "memgraph" |
| ""       | "gc"                  | ["GARBAGE COLLECTION"] | "running" | {db_name: "tenant1", exclusive_lock: false, phase: "unlink", trigger: "forced"} | 2026-10-19 12:01:18.288188000[Etc/UTC] | 5          | "tenant1"  |
+----------+-----------------------+------------------------+-----------+---------------------------------------------------------------------------------+----------------------------------------+------------+------------+

Because snapshot and garbage-collection rows always have status "running", they are suppressed when you use SHOW COMMITTING TRANSACTIONS or SHOW ABORTING TRANSACTIONS.

Permissions

By default, users can see and terminate only the transactions they have started. For all other transactions, the user must have the TRANSACTION_MANAGEMENT privilege which the admin assigns with the following query:

GRANT TRANSACTION_MANAGEMENT TO user;

The privilege to manage all the transactions running in Memgraph is revoked using the following query:

REVOKE TRANSACTION_MANAGEMENT FROM user;

An auth transaction belongs to its session’s current database. A user with the TRANSACTION_MANAGEMENT privilege on that database can see its queries and terminate it without the AUTH privilege.

If you are connecting to Memgraph using a client, you can pass additional metadata when starting a transaction (if the client supports additional metadata) which will be visible when running the SHOW TRANSACTIONS; query, thus allowing you to identify each transaction precisely.

The Python example below demonstrates how to pass metadata for both an implicit and explicit transaction:

import neo4j
 
def main():
  driver = neo4j.GraphDatabase.driver("bolt://localhost:7687", auth=("user","pass"))
 
  s1 = driver.session()
  tx = s1.begin_transaction(metadata={"where":"in explicit tx", "my_uuid":1})
  tx.run("MATCH (n) RETURN n LIMIT 1")
 
  s2 = driver.session()
  query=neo4j.Query("SHOW TRANSACTIONS", metadata={"where":"in implicit tx", "my_uuid":2})
  print(s2.run(query).values())
 
  tx.close()
  s1.close()
  s2.close()
 
if __name__ == '__main__':
  main()

Terminate transactions

To terminate one or more transactions, you need to open a new session and use the following query:

TERMINATE TRANSACTIONS "tid", "<tid2>", "<tid3>", ... ;

The tid is the transactional ID that can be seen using the SHOW TRANSACTIONS; query.

The TERMINATE TRANSACTIONS query signalizes to the thread executing the transaction that it should stop the execution. No violent interruption will happen, and the whole system will stay in a consistent state.

The result has two columns, transaction_id and killed. A transaction reports killed: true only if it was actually found, the caller was allowed to terminate it, and it was still running. Ids that do not match a running transaction, and matches the caller is not authorized to terminate, both report killed: false — an unauthorized match is indistinguishable from a missing id, so the query never reveals that somebody else’s transaction exists.

Terminate all transactions

Instead of copying ids out of SHOW TRANSACTIONS one at a time, you can terminate everything at once with the "*" wildcard:

TERMINATE TRANSACTIONS "*";

This terminates every transaction the caller is authorized to terminate, following the same rules as the id list form:

• Scope: all transactions visible through SHOW TRANSACTIONS, across all databases — not just the caller’s current database.
• Authorization: a transaction is terminated if the caller owns it, or holds the TRANSACTION_MANAGEMENT privilege on the database that transaction is running on. A user without the privilege terminates only its own transactions; the query does not fail, it simply returns fewer rows. Transactions the caller may not terminate are absent from the output rather than reported as killed: false, so no transaction id is leaked.
• The caller’s own transaction is skipped, so the session issuing the sweep survives it and can read back the result.
• Output: the usual transaction_id and killed columns, one row per terminated transaction ordered by ascending transaction id (oldest first), and zero rows if nothing matched.
• Transactions that are already committing or aborting are skipped, the same as with the id list form.

The wildcard must be the only argument. Mixing it with ids, such as TERMINATE TRANSACTIONS "*", "9223372036854794885", raises an error.

Transaction ids, including "*", must be string literals. Query parameters such as $id aren’t supported and cause a syntax error.

memgraph> TERMINATE TRANSACTIONS "*";
+-----------------------+-----------------------+
| transaction_id        | killed                |
+-----------------------+-----------------------+
| "9223372036854794885" | true                  |
| "9223372036854794891" | true                  |
+-----------------------+-----------------------+
2 rows in set (round trip in 0.001 sec)

Terminate custom procedures

If you want to be able to terminate custom procedures, crucial parts of the code, such as while and until loops, or similar points where the procedure might become costly, need to be preceded with CheckMustAbort() function.

Example

Managing transactions is done by establishing a new connection to the database.

docker ps

docker exec -it CONTAINER_ID mgconsole

Show and terminate transactions

The output of the SHOW TRANSACTIONS command shows that a query is being run on the memgraph database as part of the transaction ID “9223372036854775809”.

memgraph> SHOW TRANSACTIONS;
+----------+-----------------------+-------------------------------------------------------------------------------------------+-----------+----------+----------------------------------------+------------+------------+
| username | transaction_id        | query                                                                                     | status    | metadata | start_time                             | elapsed_ms | database   |
+----------+-----------------------+-------------------------------------------------------------------------------------------+-----------+----------+----------------------------------------+------------+------------+
| ""       | "9223372036854775810" | ["SHOW TRANSACTIONS"]                                                                     | "running" | {}       | 2026-10-19 12:11:16.345268000[Etc/UTC] | 0          | "memgraph" |
| ""       | "9223372036854775809" | ["UNWIND range(1, 100000) AS a UNWIND range(1, 100000) AS b WITH a WHERE a < 0 RETURN a"] | "running" | {}       | 2026-10-19 12:11:14.342553000[Etc/UTC] | 2002       | "memgraph" |
+----------+-----------------------+-------------------------------------------------------------------------------------------+-----------+----------+----------------------------------------+------------+------------+

To terminate the transaction, run the following query:

TERMINATE TRANSACTIONS "9223372036854775809";

Upon the transaction termination, the following confirmation will appear:

memgraph> TERMINATE TRANSACTIONS "9223372036854775809";
+-----------------------+-----------------------+
| transaction_id        | killed                |
+-----------------------+-----------------------+
| "9223372036854775809" | true                  |
+-----------------------+-----------------------+
1 row in set (round trip in 0.000 sec)

The following message will appear in the session in which the long-running query was being run:

memgraph> UNWIND range(1, 100000) AS a UNWIND range(1, 100000) AS b WITH a WHERE a < 0 RETURN a;
Client received query exception: Transaction was asked to abort by another user.

Manage sessions

A session is one client connection to Memgraph over Bolt. You can list the open sessions and close any of them from another connection, for example an idle (often pooled) connection that still has a database selected and makes a DROP DATABASE query without FORCE fail with the Cannot delete <name>, it is currently being used. error. With FORCE, Memgraph closes such sessions itself. Available since Memgraph 3.14.

Session queries run on data instances (MAIN and REPLICA), and each instance lists and closes only the sessions connected to it. On a high availability coordinator they fail with the Coordinator can run only coordinator queries! error. Run them on their own, not inside an explicit transaction (one you start with BEGIN), where they raise an error.

Show sessions

To list the open sessions, run:

SHOW SESSIONS;

Each row is one session that is currently logged in. A connection that hasn’t logged in yet, or that has logged off, isn’t listed. After it logs on again it reappears with the same session_id. If another user logs on, the row shows that user and the database of the new login:

The SHOW SESSIONS query shows your own sessions, and the sessions on every database where you have the TRANSACTION_MANAGEMENT privilege. A session that isn’t using a database counts as using the default database, memgraph. When authentication is disabled, every connection counts as the same user, so you see all sessions. With user impersonation, a connection counts as the impersonated user, and its queries are checked against that user’s privileges.

In the following example, admin has the TRANSACTION_MANAGEMENT privilege on every database, and alice has two idle connections open, one on the analytics database and one on the memgraph database. The session running the query is listed too:

+----------------------------------------+----------+-------------+------------------------------+
| session_id                             | username | database    | login_timestamp              |
+----------------------------------------+----------+-------------+------------------------------+
| "eba078f8-2c56-4e22-bf47-4545ac9d4b1a" | "admin"  | "memgraph"  | "2026-10-07 10:30:33.022574" |
| "e9e40294-db31-4122-9875-75affefc1130" | "alice"  | "memgraph"  | "2026-10-07 10:30:32.391885" |
| "f9892d9b-ca91-4e16-b3df-1ead198cc846" | "alice"  | "analytics" | "2026-10-07 10:30:32.228485" |
+----------------------------------------+----------+-------------+------------------------------+

Terminate sessions

To close one or more sessions, run the following query from another connection:

TERMINATE SESSIONS 'SESSION_ID' [, 'SESSION_ID' ...];

SESSION_ID is a session_id from the SHOW SESSIONS output, written as a string literal. Query parameters such as $id aren’t supported and cause a syntax error. Any other literal value raises the Session id must be a string. error.

You can terminate your own other sessions without any privilege. To terminate another user’s session, you need the TRANSACTION_MANAGEMENT privilege on the database that session is using (the default database, memgraph, if it isn’t using one). The session that runs the TERMINATE SESSIONS query can’t terminate itself.

The result has two columns, session_id and killed, with one row per id in the query, in the same order. A row reports killed: true if the session was found and you were allowed to close it. This means the close was requested: a session that is busy with a query can still appear in SHOW SESSIONS until that query returns. An id that matches no session, an id you’re not allowed to terminate, the id of the session running the query, and every repeat of an id already in the list all report killed: false.

For example, to close alice’s analytics session (the second id doesn’t match any session):

TERMINATE SESSIONS 'f9892d9b-ca91-4e16-b3df-1ead198cc846', '00000000-0000-0000-0000-000000000000';

+----------------------------------------+--------+
| session_id                             | killed |
+----------------------------------------+--------+
| "f9892d9b-ca91-4e16-b3df-1ead198cc846" | true   |
| "00000000-0000-0000-0000-000000000000" | false  |
+----------------------------------------+--------+

What happens to a terminated session depends on what it’s doing:

• Idle: Memgraph closes the session immediately.
• Running a query: Memgraph aborts the query’s transaction and closes the session as soon as the query returns. Most queries stop right away. A query that doesn’t check for termination, such as a long-running function call, runs until it finishes, and its transaction isn’t committed.
• In an open explicit transaction (it ran BEGIN and hasn’t committed): Memgraph rolls the transaction back. Its uncommitted changes are discarded and the writes it holds are released, so conflicting transactions can continue.
• Committing: the commit isn’t interrupted; it completes.

The client of a terminated session loses its connection:

• A query it’s running fails with the transient Transaction was asked to abort by another user. error. A query that doesn’t check for termination fails when it finishes, with the transient Aborting transaction commit because the transaction was requested to stop from other session. error.
• An idle client gets a connection error on its next request, and the driver opens a new connection for the request after that. Driver retry helpers (for example, the Python driver’s execute_read) retry on that error, so their request succeeds.

Because the error is transient, driver retry helpers (for example, the Python driver’s execute_write) retry the transaction on a new connection, and the retry can commit. Terminating a session doesn’t stop an application that uses retry helpers from running the same work again.

Isolation levels

In database systems, isolation determines how transaction integrity is visible to other users and systems.

A lower isolation level allows many users to access the same data at the same time but increases the number of concurrency effects (such as dirty reads or lost updates). A higher isolation level secures data consistency but requires more system resources and increases the chances that one transaction will block another.

Memgraph currently supports three isolation levels, from the highest to the lowest:

• SNAPSHOT_ISOLATION (default) - guarantees that all reads made in a transaction will see a consistent snapshot of the database, and the transaction itself will successfully commit only if no updates it has made conflict with any concurrent updates made since that snapshot. Protects users from observing Dirty Read, Non-repeatable Read and Phantom phenomena as described in ANSI/ISO SQL-92 standard.
• READ_COMMITTED - guarantees that any data read was committed at the moment it is read. It protects users from observing Dirty Read phenomenon as described in ANSI/ISO SQL-92 standard.
• READ_UNCOMMITTED - one transaction may read not yet committed changes made by other transactions. Doesn’t protect users from any of the three phenomena described in ANSI/ISO SQL-92 standard. In order to not mess up data consistency, this isolation level should only be used in the read-only access mode.

Based on Adya’s classification of phenomena, we can further write:

In terms of Adya’s isolation levels, Memgraph supports: PL-1, PL-MSR (Monotonic Snapshot Reads), PL-2, PL-2’, PL-2”, PL-2L, PL-CS (Cursor Stability) and PL-2+ (consistent view).

You can find tests for these phenomena here.

To check the current (runtime) isolation level of the database you are connected to, run the following query and read the storage_isolation_level field:

SHOW STORAGE INFO ON CURRENT DATABASE;

The unscoped SHOW STORAGE INFO only reports global_isolation_level, which is the startup-default isolation level (the --isolation-level flag) and does not reflect runtime SET GLOBAL TRANSACTION ISOLATION LEVEL changes.

IN_MEMORY_ANALYTICAL storage modes offers no isolation levels and no ACID guarantees. Multiple transactions can write data to Memgraph simultaneously. One transaction can therefore see all the changes from other transactions.

ON_DISK_TRANSACTIONAL storage mode uses only snapshot isolation.

Set the isolation level

Memgraph can work in IN_MEMORY_ANALYTICAL, IN_MEMORY_TRANSACTIONAL or ON_DISK_TRANSACTIONAL storage mode. IN_MEMORY_TRANSACTIONAL is the default mode in which Memgraph runs on startup.

When Memgraph is running in the IN_MEMORY_TRANSACTIONAL mode you can change the isolation level, change the --isolation-level configuration flag to any of the supported values.

You can also change the initially set isolation level when Memgraph is running using the following query:

SET <scope> TRANSACTION ISOLATION LEVEL <isolation_level>

<scope> defines the scope to which the isolation level change should apply:

• GLOBAL - apply the new isolation level globally
• SESSION - apply the new isolation level only for the current session
• NEXT - apply the new isolation level only for the next transaction in the current session

A SESSION setting lasts for the client connection. A failed query or a rollback keeps it, including the Bolt RESET a driver sends after a failure. Switching to another user on the same connection (the driver re-authenticates, sending LOGOFF and LOGON) clears both a SESSION setting and a pending NEXT one. The new user’s transactions then run at the database’s current isolation level.

<isolation_level> defines the isolation level:

• SNAPSHOT ISOLATION
• READ COMMITTED
• READ UNCOMMITTED