# migrateDown() function · @imqueue/pg-prisma

Source: https://imqueue.org/api/pg-prisma/latest/pg-prisma.migratedown/
Published: 2026-08-01
Author: @imqueue maintainers (https://github.com/imqueue)
Package: @imqueue/pg-prisma 1.0.1 — generated reference, not hand-written

Roll back the most recently applied Prisma migrations.

**Signature:**

```typescript
export declare function migrateDown(options: MigrateDownOptions): Promise<MigrateDownResult>;
```

## Parameters


| Parameter | Type | Description |
| --- | --- | --- |
| options | [MigrateDownOptions](https://imqueue.org/api/pg-prisma/latest/pg-prisma.migratedownoptions/) | Connection string, paths, how many steps, and the mode flags. |


**Returns:**

Promise<[MigrateDownResult](https://imqueue.org/api/pg-prisma/latest/pg-prisma.migratedownresult/)>

The migration names processed, newest first.

## Exceptions

Error propagated from a failing `down.sql`, after the transaction has been rolled back — so a failed step leaves the migration applied rather than half-undone.

## Remarks

Prisma has no native "down", so this reconstructs one. Each migration folder may hold a hand-written `down.sql`, which is authoritative and used as-is. When there is none, one is generated by asking `prisma migrate diff` for the difference between the migration set including the target and the set without it, using a throwaway shadow database — because a migration-set diff has to replay the migrations somewhere. The generated file is written into the migration folder, so it can be reviewed and corrected before it is ever used again.

Rolling one migration back means running its `down.sql` and deleting its `_prisma_migrations` row in a single transaction, then optionally removing the folder. Migrations are processed newest first, since each down script assumes the later ones are already undone.

Generated SQL deserves a sceptical eye: a diff can express a dropped column but not the data that was in it, so a generated down script recreates structure and cannot restore content. Review the file rather than trusting it, and prefer `generateOnly` on a first pass.

Every input is a parameter — the database URL, the paths, the reporter — and no global or environment variable is read, so this is usable as a library function. It does shell out to `npx prisma migrate diff`, and it creates and drops a database on the same server as `databaseUrl` for the shadow.

## Example


```typescript
const { processed } = await migrateDown({
    databaseUrl: process.env.DATABASE_URL!,
    migrationsDir: join(root, 'prisma', 'migrations'),
    projectRoot: root,
    steps: 1,
    log: console.log,
});
```