Promotion is a modelled path, not a calendar invite
A pipeline is an ordered list of environments. Each change script walks that list with its own status, required approvals, and a rollback script prepared before anyone clicks execute.
What a pipeline actually contains
Any number of environments, each with one or more connections. A simple DEV → PROD flow and a six-stage path with QA and staging use the same model.
A stage can require one approver or a minimum count. Authoring and approving are separate permissions, so a writer cannot rubber-stamp their own production deploy.
Run a stage yourself, or mark it to start automatically when the previous environment completes. Promotion is driven by approvals and by the stage before it, never by a clock: nothing reaches production because a scheduled job fired at 2am.
A down script is generated alongside the change. Where the engine allows it, the rows a destructive statement is about to change are preserved before the forward script runs, so the undo has something to restore.
What you see while it runs
| Stage status | Meaning |
|---|---|
| Queued / Pending | Waiting for a previous stage, an approval, or a person to start execution. |
| In progress | The Executor is executing. A stuck-script monitor flags runs that remain in this state too long. |
| Completed / Failed / Rejected | Terminal outcomes for that environment. Failed stages can be retried; there is no resume from the middle of a script. |
| Rolling back / Rolled back | The prepared down path is running or finished. Stage-order blockers stop a rollback that would leave later environments ahead of earlier ones. |
The down path is classified before anyone runs the up path
On save, the script is labelled Reversible, Partially reversible, Needs protection, or Irreversible. That label is what reviewers see, not a paragraph of hope in the ticket.
Fully or partially reversible
A down script is generated with the change. Partial means some statements reverse cleanly and others do not the label is there so nobody assumes the whole file is a one-click undo.
Needs protection
Destructive work is set aside at apply instead of destroyed, and the rollback brings it back. Where the engine allows it, that happens without copying the data at all.
Irreversible
There is no safe automatic down path. The product still records the attempt; it will not pretend a DROP of unbacked data can be undone from a generated script.
Data comes back, not just the schema
Most migration tools stop at schema: the undo is a script someone wrote, and once a DELETE or UPDATE has run there is nothing left to restore. Migratrix keeps the rows a statement changes before it runs, so rolling back puts the data back, not only the table definition.
Undo matched to what the statement did
An INSERT is undone by deleting the inserted rows by key. An UPDATE restores the old values of only the columns it changed. A DELETE re-inserts the rows it removed. Reversible DDL gets its exact inverse. Nothing is copied that the undo does not need.
Instant parks, even on huge tables
Where the engine allows it, nothing is copied: the table is parked by rename, a dropped column is renamed aside instead of dropped, and whole partitions are exchanged out on engines that support it. These take the same time at a thousand rows or a billion.
Blocked, not gambled
If a destructive statement cannot be protected, the apply is refused. Changing that is a deliberate decision an operator makes, recorded like any other. How much one statement may preserve is capped as well, so filling a tablespace is a decision rather than a surprise.
See the rollback before you run it
Before you confirm, the exact rollback SQL is shown with its scope: rows to revert and snapshots to restore. Snapshots live in a dedicated migratrix_snapshots schema. If retention has already dropped the saved rows, the preview says the rollback can no longer revert them.
Stage-order on rollback
You cannot roll back an earlier environment while a later one has already moved on. The blocker exists so PROD does not sit ahead of a rolled-back QA.
What the pipeline owns, and what stays yours
They are not a replacement for application CI
Pipelines govern database change scripts. Your application build and deploy stay where they are. GitOps can connect the SQL files to the same review flow your team already uses.
They do not checkpoint inside a script
A failed run can be retried. It does not resume from statement 47. Write scripts that are safe to re-run, or split a large change into more than one change script.
Source can be manual or GitOps
Author in Migratrix, or bind the pipeline to a GitHub or GitLab repository and let merge events create the change script. Both still walk the same approval and rollback path.
Approvals, auto-start, and why a stage can refuse to move
| Setting | Default and effect |
|---|---|
| Requires approval | Off on a new environment. When on, execute is blocked until the number of approvals meets the minimum. |
| Minimum approvals | 1. The UI shows this as “Yes (N approvals)” on the environment. Authoring and approving are different permissions. |
| Auto-start | Off. When on, a stage can move to In progress after the previous stage completes and the approval threshold is met no second click. |
| Later stages | Sit in Queued until the prior environment completes. You cannot skip ahead and leave QA unapplied. |
| Multiple connections | A stage can target more than one connection. The UI shows the primary name plus a count. Each connection gets its own execution result. |
| Entity locks | Every table the script will create, alter, drop or write to is claimed while it runs. A second script that touches the same table is blocked from promoting until the first one finishes. |