Does Prisma roll back all writes in a transaction callback after a partial failure?

Short answer

Yes. With an interactive transaction — prisma.$transaction(async (tx) => { ... }) — if the callback throws or rejects, Prisma aborts the transaction and the database rolls back every write made through the tx client, including statements that executed successfully before the failing one. Statements that ran earlier were never durable; they only become permanent at commit, and a thrown error prevents commit entirely. This is standard database transaction semantics, not Prisma-specific magic: Prisma opens a transaction on a dedicated connection, runs your callback against it, and issues COMMIT only if the callback resolves.

Where partial writes actually survive

The rollback guarantee has sharp edges you should check in your own code:

• Using the outer client. If any write inside the callback uses prisma instead of the tx argument, that write runs on a different connection outside the transaction and will persist after rollback. This is the most common cause of "Prisma didn't roll everything back" reports.
• Non-database side effects. Emails, HTTP calls, cache writes, and file I/O inside the callback are never rolled back. Move them after the transaction resolves.
• Non-transactional operations. Some DDL and certain raw statements are not transactional depending on the engine (notably many DDL statements in MySQL/MariaDB cause implicit commits). Review raw SQL carefully.

PostgreSQL vs MySQL

For ordinary DML (INSERT/UPDATE/DELETE), rollback behavior is equivalent on both: the whole transaction is undone. The differences are at the margins. MySQL's InnoDB implicitly commits on most DDL, so a schema-altering raw statement mid-callback can commit earlier writes permanently — PostgreSQL's transactional DDL does not have this problem. Savepoints matter mainly for nested transaction APIs: Prisma maps nested $transaction calls to savepoints on supported providers, so an inner rollback releases to the savepoint without touching the outer transaction's earlier work. An uncaught error that escapes the outermost callback still rolls back everything.

Connection lifecycle

The interactive transaction pins one connection from the pool for the full callback duration, whether it ends in commit or rollback. After a failure the connection is released back to the pool once the rollback completes. This is why long callbacks risk pool exhaustion and why the transaction timeout option exists.

Verify it yourself

Don't take any version's behavior on faith — test against your actual Prisma version and provider:

try {
  await prisma.$transaction(async (tx) => {
    await tx.widget.create({ data: { name: 'A' } });
    throw new Error('simulated failure');
    // await tx.widget.create({ data: { name: 'B' } });
  });
} catch {}
const count = await prisma.widget.count();
// expect 0: write A was rolled back with the aborted transaction

Then repeat with one write issued via the outer prisma client inside the callback and confirm it survives — that contrast demonstrates exactly where the atomicity boundary sits. If you rely on DDL or raw statements on MySQL, add a case for those too, since connector- and engine-specific behavior there is the part most likely to surprise you.