Apply migrations

You have a hashed migration directory and a database that needs to catch up. Preview the apply, run it with integrity verification, read the resulting state in scripts and CI, and add the operational controls the target needs.

Prerequisites: a migration directory sealed with ptah migrations hash (see Generate migrations). The examples use a local SQLite file; substitute your own --db-url.

Preview with a dry run

On a fresh target, --dry-run prints every statement that would execute, without touching the database:

ptah migrations up \
  --db-url "sqlite://app.db" \
  --migrations-dir ./migrations \
  --dry-run

Expected output on stdout:

=== DRY RUN MODE ===
No actual changes will be made to the database

✅ Dry run completed successfully!
Would have applied 1 migrations

The statement-by-statement narration is a log record, not report output, so it goes to the log stream — stderr by default:

level=INFO msg="[DRY RUN] Would begin transaction"
level=INFO msg="[DRY RUN] Would execute SQL" sql="CREATE TABLE \"users\" ..."
level=INFO msg="[DRY RUN] Would commit transaction"

Both --log-level and --log-format apply to it: --log-level warn drops the narration and leaves only the stdout report, and --log-format json moves every record — report lines included — onto stdout as one JSON object per line, which keeps ptah migrations up ... | jq parseable. See Execution controls.

Apply with integrity verification

ptah migrations up \
  --db-url "sqlite://app.db" \
  --migrations-dir ./migrations \
  --verify-sum

Expected output includes:

=== MIGRATE UP ===
Dialect: sqlite
Transaction mode: file

Current version: 0
Total migrations: 1
Pending migrations: 1

✅ Migrations completed successfully!
Database is now at version: 1785255952

A hashed directory (one that carries ptah.sum or atlas.sum) is always verified before anything runs, and the apply aborts on drift — the same check ptah migrations validate performs. A directory without a sum file is not gated on this native surface. --verify-sum additionally makes a missing sum file itself an error, so set it for shared environments where the directory must be hashed. ptah-compat migrate apply refuses a never-hashed Atlas directory outright, because Atlas does; see Integrity and safety.

--verify-sum is registered on migrations up, down, status and push. The requirement is the same on each — carry a sum, and match it — but on the first three the subject is the directory the run pulled, while on push it is the local directory about to be published.

Either check compares the directory against the sum stored beside it, so what it establishes depends on where the directory came from. See Apply from an OCI registry for what that means when the directory is a registry artifact.

Applied versions land in the revision table. Rerunning the same command is a safe no-op:

Pending migrations: 0
✅ Database is already up to date!

Check status

ptah migrations status \
  --db-url "sqlite://app.db" \
  --migrations-dir ./migrations

Expected output includes:

=== MIGRATION STATUS ===
Current Version: 1785255952
Total Migrations: 2
Applied Migrations: 1
Pending Migrations: 1
Out-of-order Migrations: 0
Status: ⚠️  Pending migrations available

For scripts, --json prints the same state as one object:

ptah migrations status \
  --db-url "sqlite://app.db" \
  --migrations-dir ./migrations \
  --json

{
  "current_version": 1785255953,
  "applied_migrations": [1785255952, 1785255953],
  "pending_migrations": [],
  "out_of_order_migrations": [],
  "total_migrations": 2,
  "has_pending_changes": false
}

Set --exit-code in CI when pending migrations should fail the job: the command then exits 1 while pending work exists and 0 once the database is up to date.

Execution controls

The defaults are safe for most runs; three controls matter once several people and pipelines share a directory:

Transaction mode (--tx-mode): file (default) wraps each migration in its own transaction; all runs the selected batch in one; none disables wrapping. A migration may select file or none with a leading -- atlas:txmode <mode> header, or with -- +ptah no_transaction. A blank line after that header is accepted but not required. Explicit file modes conflict with global all.

Ptah transaction, timeout, and online-DDL directives are significant only before the first executable statement. Atlas transaction mode uses its own stricter header rule described below. A directive written below the statements it claims to govern is not honored — and it is not dropped in silence either. Ptah reports it at WARN on stderr, naming the file, the line, the directive and how to fix it, because an operator who writes txmode none, sees exit 0, and believes the file ran outside a transaction is the failure this rule exists to prevent. The -- atlas: spelling keeps Atlas’s own stricter acceptance inside that region: only the unbroken run of line comments that begins on line 1, each starting in column 1. A leading blank line, an indented directive, or a blank line between the directive and an earlier comment all put it outside that block, so Atlas CE ignores it and so does Ptah — with the same warning. -- +ptah directives accept the whole region, blank lines and indentation included.

The region uses the target database’s comment grammar, read from the same lexer options Ptah splits the file’s statements with — never from a separate list of dialects, which is how the two would drift apart. A leading # comment therefore stays part of the header wherever that reader treats it as a comment, which is every supported target except SQL Server, and does not hide the no_transaction, lock_timeout or statement_timeout directives that follow it. On SQL Server # is not a comment, so a directive below one really does sit below the first non-comment line and Ptah reports it.

The same grammar decides where a -- comment begins. MySQL and MariaDB start one only when a whitespace or control character follows the second dash, so a -- separator line stays in the header — including its -- \r\n form and a -- line carrying nothing but its line terminator — while --x, which those two read as SQL rather than as a comment, ends the header there.

Before a connection exists the dialect is unresolved, and there Ptah reads the header the widest way any target would. That direction is deliberate: loading a file happens first and its verdict is final, so a header cut short there would refuse a correctly placed directive as being below the first SQL statement and offer a remedy — move it up — that the line already satisfies. Ptah then resolves the effective timeouts and transaction mode with the execution dialect before it validates or runs the migration.

Position and value are separate facts, and a bad value is not demoted to a position warning. A -- +ptah directive whose key Ptah recognizes but whose value it cannot read — no_transaction=maybe, lock_timeout=soon — fails the run wherever the line sits, and the refusal names the position too, so you are not told the value is nonsense, told nothing about the line being in the wrong place, and left to discover that on the next run. A timeout key written with no value at all — -- +ptah lock_timeout — fails the same way, and it does so whatever else shares the line: a neighboring field Ptah can read says nothing about whether the timeout has a value. A bare word Ptah does not recognize as a directive (-- +ptah revisit this) is an ordinary comment and is neither refused nor reported, and neither is a word inside an ordered -- +ptah check line, whose quoted arguments are that directive’s own grammar rather than key=value fields.

The -- atlas: spelling deliberately has no equivalent refusal. Measured on Atlas CE v1.3.0, migrate apply over a directory carrying -- atlas:txmode bogus exits 1 when the line is the header and 0 when it sits below the statement. Refusing the second would exit non-zero where Atlas CE exits 0, so Ptah reports it and applies the directory, as CE does.
Batch limit (--limit): apply only the first N pending migrations — useful for staged rollouts and verifying one step at a time. --allow-dirty is the explicit recovery escape hatch that proceeds past a dirty revision row. When the dirty row belongs to a migration that is still pending — the usual case, a body that failed part-way — the retry reuses that row rather than recording a second one, and skips the statements the earlier attempt committed. Before it skips anything, Ptah verifies that the committed source prefix is unchanged. Native rows carry a partial:h1: prefix checksum; Atlas-format rows carry cumulative partial_hashes. Editing only the unapplied suffix is allowed. A failed retry cannot reduce applied below the previously committed prefix, even when the transaction mode changed. Every none attempt runs its migration SQL on one pinned physical database session, so a statement such as SET search_path remains effective for the statements that follow. On server databases, revision checkpoints remain on the original connection and cannot be redirected by that session state. SQLite uses the pinned session but qualifies its revision table in main, so in-memory databases do not deadlock and temporary objects cannot shadow the metadata. A resumed attempt uses a fresh session: Ptah replays recognized session-control statements from the verified prefix, skips recognized durable DDL and DML, and refuses prefixes that created temporary objects or whose session-local effect cannot be classified safely. A none body cannot contain top-level transaction-control statements such as BEGIN, COMMIT, ROLLBACK, savepoint commands, MySQL or MariaDB SET autocommit, or SQL Server SET IMPLICIT_TRANSACTIONS. Ptah validates the complete body and pins its physical session before changing revision metadata, so either failure leaves a new version absent and preserves an existing dirty row unchanged. MySQL and MariaDB also reject transaction-control statements in file mode: Ptah owns that file transaction, and changing autocommit inside the body would make a post-DDL checkpoint ambiguous. Their revision metadata, default storage engine, and every existing base table in the selected database must use InnoDB. A migration that explicitly selects another storage engine, resets an engine setting to DEFAULT, or inherits one through CREATE TABLE ... LIKE is refused before its first statement. DEFAULT can resolve differently from the session default that preflight verified. On MySQL, the migration account must hold TRIGGER at database or global scope so Ptah can see a complete trigger catalog. MariaDB exposes each trigger’s identity and target table without TRIGGER, so it does not require that privilege for this catalog check. Ptah refuses MySQL file mode when it cannot prove complete visibility. The MySQL grant must be global or must name the selected database exactly in SHOW GRANTS. Ptah decodes escaped literal wildcard characters in the database name, but deliberately does not infer coverage from an unescaped % or _ pattern because MySQL’s partial_revokes setting changes that pattern’s meaning. Every sql_mode assignment is also refused because changing grammar or quoting rules after preflight can make the server execute SQL that Ptah did not inspect. A session that already enables parser-changing ANSI_QUOTES, MSSQL, or NO_BACKSLASH_ESCAPES behavior through the connection DSN or server default is refused for the same reason. Durable server-state operations such as SET GLOBAL, SET PERSIST, RESET, and CREATE, ALTER, or DROP DATABASE are refused for the same reason: their effects do not share the InnoDB transaction containing the witness. SELECT or TABLE with INTO OUTFILE or INTO DUMPFILE is also refused because it writes outside that transaction. The equivalent SCHEMA statements and USE are rejected as well; select the target database in --db-url so Ptah can validate the database it will modify. References to another database are rejected even when qualified directly. Ptah also refuses executable comments, CALL, prepared or dynamic SQL, table locks, definitions of views, triggers, routines, and events, references to existing views or trigger-bearing tables, and calls to stored routines. Those forms can hide work that does not share the witness transaction. A custom MigrationFunc is opaque for the same reason and must use none; a StatementInterceptor is also opaque because it can replace the inspected statement with different SQL. MySQL-family file mode accepts directly executed SQL-backed migrations only. Statement-level rejection diagnostics identify the statement number and safety class without echoing the SQL, which may contain credentials. Migration-function and interceptor refusals identify the affected direction instead because their inner statements are opaque. The migration advisory lock serializes Ptah clients that use the same lock name. It cannot freeze DDL from a client that ignores that lock. Do not run out-of-band DDL from the safety preflight until the migration finishes. Pre-migration checks are not rerun after committed progress because they describe the original pre-migration state. Automatic continuation is up-direction only: a row left dirty by an interrupted rollback is refused so up SQL cannot be resumed from a down-statement offset. Use ptah migrations repair when the row cannot be resumed automatically: an interrupted rollback, a process whose last statement has an unknown outcome, changed or unverifiable committed-prefix metadata, an edit that changed the file’s statement count, or a dirty row for a migration whose file was rebased away. Legacy dirty rows without prefix metadata may resume only while their full-file checksum still matches.
Execution order (--exec-order): linear (default) fails when a merge landed a pending migration below the current version; linear-skip warns and leaves it pending; non-linear applies it. Status reports such versions as out-of-order.
Timeouts and locks: --statement-timeout, --lock-timeout, and --migration-lock-timeout bound long DDL and the session-level advisory lock that keeps two migrators from racing. A migration that resolves to none cannot use statement or lock timeouts. Ptah rejects the combination before executing SQL or changing the revision row. A file-level file override under global none restores the transaction and may use timeouts. SQL-backed non-transactional migrations record a durable progress marker before and after each autocommit statement. A custom Go MigrationFunc remains opaque and is recorded only when it returns.

What `--tx-mode all` cannot carry

--tx-mode all runs every selected migration in one transaction. Three other features are scoped to a single migration, so they do not compose with it, and each is refused before any SQL runs rather than discovered one migration at a time.

Combined with `--tx-mode all`	Result
A target with no transactional DDL	refused: `tx-mode all is not supported for dialect "…": this target commits schema changes as they run, so a failed migration cannot be rolled back as a unit`
A migration declaring pre-migration checks	refused: `migration N declares pre-migration checks, which cannot run with tx-mode all`
A migration declaring timeouts	refused: `migration N declares timeouts, which cannot run with tx-mode all`
A migration selecting its own transaction mode	refused: an explicit file-level `file` or `none` conflicts with global `all`

The reason is the same in the middle two cases: one transaction spans the whole run, so a per-migration timeout would bound the entire batch rather than the file that asked for it, and a pre-migration check would read state the batch has already changed. The remedy is the default per-file mode, or removing the directive from that migration.

The first row is the engine rather than a Ptah policy, and it is decided by the target’s transactional-DDL capability rather than by a list of dialect names. MySQL, MariaDB, ClickHouse and Spanner commit DDL as it runs.

Timeouts themselves are not tied to that capability and reach every target whose server takes a session or transaction timeout; a target that takes none refuses --lock-timeout and --statement-timeout by naming the engine.

Run logging (--log-level, --log-format): --log-level debug|info|warn|error selects how much of the run is narrated — warn silences the per-statement dry-run narration — and --log-format text|json selects the encoding. json moves every record, the stdout report included, onto stdout as one JSON object per line.

See Configuration for the ptah.yaml equivalents of every control.

`--allow-dirty` means two different things

One spelling, two surfaces, two unrelated safety questions. The collision is permanent — the compatibility surface registers the flag Atlas registers, and the native surface registers the one Ptah has always had — so read the flag against the command it was typed after:

command	what is dirty	what the flag asks for
`ptah migrations up`	a revision row, left by a migration body that failed part-way	a verified retry of that body, skipping only an unchanged committed prefix
`ptah-compat migrate apply`	the schema, which already holds objects this history did not create	adopt that database anyway and apply into it

Neither can be expressed in terms of the other, and neither implies the other. Measured against the pinned community binary, its --allow-dirty releases no dirty-revision guard at all: an operator who passes it there has said nothing about revision rows, and one who passes it to ptah migrations up has said nothing about adopting a populated database.

Native ptah migrations up has no adoption gate, so nothing refuses a database it did not create; running it against one fails on the first object that already exists. ptah migrations baseline is the native way to adopt an existing database, and --shadow-db verifies that the baselined history reproduces the schema it was pointed at.

Operational hooks

Production-like runs should be configured, not wrapped in ad hoc shell scripts. ptah migrations up supports:

--pre-up-hook — a shell command that must exit 0 before anything is applied (rollback runs have --pre-down-hook).
--webhook — a URL that receives migration metadata and must return HTTP 200 before the run proceeds.
--pg-dump-to / --mysqldump-to — a directory where a backup is written before migrations are applied.
Revision-table placement (--migrations-table, --migrations-schema) and Prometheus metrics (--metrics-addr).
--migrations-engine — the storage engine the revision table is created with. It exists for ClickHouse, where a replicated deployment needs ReplicatedMergeTree(...) or the migration history lives on one node while every replica reports itself consistent; see the ClickHouse revision table’s storage engine. An engine the revision table cannot be is refused before any statement runs.

All of these can live in ptah.yaml instead of the command line; see Configuration.

Apply from an OCI registry

up, status, and down accept an oci:// reference as the migrations directory, so the artifact your CI published is exactly what production runs — pin it by immutable digest:

ptah migrations push \
  oci://ghcr.io/acme/app-migrations \
  --migrations-dir ./migrations \
  --verify-sum

ptah migrations up \
  --db-url "$DATABASE_URL" \
  --migrations-dir oci://ghcr.io/acme/app-migrations@sha256:<digest> \
  --verify-sum

Pin the digest deliberately: --verify-sum checks the pulled directory against the sum shipped inside the same artifact, so over a movable tag it proves the files are internally consistent, not that they are the reviewed ones. up prints that qualification, along with the digest the tag resolved to and the reference that pins it, whenever a sum verifies over a tag-resolved artifact. The run still succeeds; a digest reference gets no such line.

To keep the readable name and the pin together, write both:

ptah migrations up \
  --db-url "$DATABASE_URL" \
  --migrations-dir oci://ghcr.io/acme/app-migrations:release@sha256:<digest> \
  --verify-sum

The digest selects the bytes and is verified against what the registry returns; the tag is a label. Repointing :release afterwards changes nothing about what this command runs, and this reference counts as a digest pin, so it gets no movable-tag qualification.

See OCI registry artifacts for authentication, tag and digest semantics, referrer reports, and CI wiring.

Failure modes

Integrity drift aborts before anything runs (exit 2):

error: migration sum verification failed:
migration directory does not match ptah.sum:
  changed: 0000000002_add_posts.up.sql

Destructive pending migrations are refused by default (exit 2); rerun with --allow-destructive after review:

error: error running migrations: pending migrations contain destructive statements; rerun with --allow-destructive after review:
- 0000000003_drop_users.up.sql:1 DS101 error: DROP TABLE permanently deletes table users and every row in it; ...

The integrity gate is covered in depth on Integrity and safety, the destructive gate on Lint and gate unsafe SQL.

A migration failed partway. The revision table records a dirty state and every later run refuses to continue until it is repaired — see Maintain migration history. A failed rollback records the same recoverable state in both revision-table formats; ptah-compat migrate down keeps the Atlas table layout but does not copy Atlas’s hidden failed-down state. Roll back migrations shows how to resume it through the native repair command.

What a failed body records depends on the transaction mode — and, on the MySQL family, on the statements themselves. The committed prefix a resume skips is only ever the prefix that really survived:

Under none, every statement commits on its own. The revision row is checkpointed after each one, so applied and the cumulative digests name exactly the statements that ran, and the retry continues at the next one.
Under file or all on PostgreSQL, CockroachDB, YugabyteDB, SQLite and SQL Server, DDL is transactional and the failure rolls the whole body back. Nothing is recorded as committed, and the retry runs the body from its first statement. An Atlas-format row written for such a failure is removed rather than left claiming progress that no longer exists.
Under file on MySQL and MariaDB, the server may commit the open transaction around DDL, so part of a failed body can survive its final rollback. Ptah does not infer that prefix from SQL keywords. Before and after each statement it updates the InnoDB revision row on the same physical transaction as the body. A server-side implicit commit therefore makes the matching witness durable; an ordinary rollback removes both user DML and its witness. Plain DML that rolls back retries from the first statement, while a durable DDL/DML prefix resumes at the first statement not witnessed as complete. Ptah pins and then discards the physical session; a retry replays safe session settings from the verified prefix before it continues. Temporary tables remain available: their DDL does not make permanent InnoDB work durable by itself, and discarding the session prevents temporary state from leaking into a retry. If a later implicit commit makes a prefix containing a temporary object durable, automatic resume refuses because that object cannot be reconstructed safely. The configured migration metadata table name is reserved. Before reading or writing revision metadata, Ptah refuses and discards a pinned session that already contains a same-named temporary table. It also rejects statements that directly reference the metadata relation, including through a schema-qualified name. If a witness committed before a failing statement whose lack of side effects cannot be proven, the row remains marked unknown and automatic retry stops for manual inspection. MySQL and MariaDB do not support all.

Recorded progress therefore excludes transactional work that a rollback undid, while non-transactional mode retains work that no rollback could undo. On MySQL and MariaDB, non-transactional mode keeps revision bookkeeping on a separate checked metadata session while the migration body runs on its own discarded session, so body-local temporary objects cannot shadow the metadata table.

A non-transactional statement was interrupted. If the process exits, the context is canceled, or its deadline expires while an autocommit statement is in flight, the revision row preserves the last known completed statement and marks the interrupted statement’s outcome as unknown. Inspect the database before repair. Ptah rejects repair --resume-from while this marker is present because the SQL may already have committed.

A concurrent index build failed on PostgreSQL (exit 2). The invalid index left behind keeps the name, so re-issuing the generated IF NOT EXISTS statement is skipped rather than retried and reports no error. Ptah refuses to run the migration while an index a conditional create expects is unusable, and names the REINDEX INDEX CONCURRENTLY that rebuilds it:

error: error running migrations: migration 1785756328 cannot be applied: PostgreSQL reports index "public"."idx_members_email" (indisvalid=false, indisready=false) unusable, and CREATE INDEX ... IF NOT EXISTS finds the name taken and skips it rather than rebuilding it, so this run would record the migration applied over a constraint that is not enforced; run REINDEX INDEX CONCURRENTLY "public"."idx_members_email", or drop the index, then run the migration again

--allow-dirty does not bypass this — retrying the body is what the refusal is about. An invalid unique index enforces nothing, so without the refusal the run would exit 0, report the database up to date, and keep accepting duplicate rows. Rebuild the index with the REINDEX the message names, or drop it so the name is free and the statement builds it, then run again. Only indexes named by CREATE INDEX ... IF NOT EXISTS are checked, and only on PostgreSQL; ordinary creates retain PostgreSQL’s normal error semantics and may be renamed or removed by later statements. Other dialects have no concurrent index build to leave half-finished. A dry run is exempt, because it records nothing. ptah migrations repair refuses on the same grounds — see Maintain migration history.

An intentional DROP INDEX followed by a matching create is allowed when the drop will execute in the current attempt. A statement skipped by dirty-resume cannot serve as that cleanup. Ptah resolves both unqualified drops and target tables through search_path, then checks the schema-level relation name. An index on another table or a non-index relation with that name is a conflict. After the body, Ptah positively verifies on the active transaction or connection that every conditional create’s statement-local schema, target table, and index name still describe a usable result. Equal raw names under different search_path values remain distinct checks.

Repair that cannot reconstruct an explicit original path checks every same-named target in PostgreSQL user schemas, so the repair session’s current path cannot hide another candidate.

A partitioned parent index created with CREATE INDEX ... ON ONLY is accepted in its expected ready-but-incomplete catalog state.

A pre-migration check blocked the migration. Nothing is applied and no revision row is written, so the run is recorded as never started. Fix the data the check guarded and re-run; no repair step and no bypass flag is involved. ptah migrations up --skip-checks exists as an emergency override, and the Atlas-compatible ptah-compat migrate apply has no such flag, matching Atlas.

Next steps

Need to undo an applied migration? Roll back migrations.
Hardening the pipeline that runs this command? Integrity and safety.
Fresh databases replaying years of history? Checkpoints.