How to fix P2034: Transaction failed due to a write conflict or a deadlock in Prisma

Enable Prisma query logging or add a middleware to capture the SQL that runs inside the transaction. This helps you see which tables and rows race against each other and whether serialization failures happen in the same transaction repeatedly.

Enable debug logging for the Client:

DEBUG="prisma:query" node ./src/index.js

Prisma middleware for targeted logging:

prisma.$use(async (params, next) => {
  if (params.action === "createMany" || params.action === "updateMany") {
    console.log("tx query", params.model, params.action, params.args);
  }
  return next(params);
});

Additionally, stream your database's deadlock or serialization logs. In Postgres the system log emits "ERROR: deadlock detected" or "ERROR: could not serialize access". Once you know the affected tables, you can adjust the transaction scope or locking behavior.

Raise the isolation level for the transaction so the database treats concurrent runs as if they executed serially. This surfaces P2034 during the commit phase and keeps the data consistent even when queries overlap.

await prisma.$transaction(
  [
    prisma.order.update({ where: { id }, data: { status: "processing" } }),
    prisma.inventory.updateMany({ where: { productId }, data: { reserved: { decrement: quantity } } }),
  ],
  {
    isolationLevel: Prisma.TransactionIsolationLevel.Serializable,
  }
);

Serializable isolation is usually more aggressive, but combining it with retries makes the application resilient to the transient conflicts that trigger P2034.

Wrap the transaction in a bounded retry loop so a conflicted transaction is attempted again after the competing transaction commits. Add a backoff to avoid thundering herds.

const MAX_RETRIES = 5;
let retries = 0;

while (retries < MAX_RETRIES) {
  try {
    await prisma.$transaction([/* operations */], {
      isolationLevel: Prisma.TransactionIsolationLevel.Serializable,
    });
    break;
  } catch (error) {
    if (error.code !== "P2034") {
      throw error;
    }
    retries++;
    await new Promise((resolve) => setTimeout(resolve, 50 * retries));
  }
}

Stop retrying after a short number of attempts to avoid locking up resources. Log each retry so you can spot whether the conflict rate is increasing under load.

If two different processes fight for the same data, serialize the work with explicit locks or a single worker.

1. Use row-level locking before the heavy writes:

await prisma.$executeRaw\`
SELECT id FROM "Order" WHERE id = $1 FOR UPDATE
\`(orderId);

2. Use Postgres advisory locks when you want to serialize by business key:

await prisma.$executeRaw\`SELECT pg_advisory_xact_lock(${customerId})\`;

3. Or queue the operation in a single worker (Redis stream, job queue) so only one process touches the record at a time.

Reducing parallel writes to the same record stops P2034 at the source.