Answer "who changed production?" in one click
Most teams can technically reconstruct a database change history from CI logs, tickets, and chat threads. That is not the same as controlling it. Migratrix makes approval and attribution a property of the system rather than a habit people have to maintain.
Where database governance usually breaks
None of these are process failures. They are what happens when the tooling has no opinion about who may do what.
Approval lives outside the system
A reviewer approves in a ticket, then someone else runs the SQL by hand. Nothing enforces that the thing approved is the thing that ran.
Shared production credentials
When several engineers use the same database login, the database's own audit log can tell you what happened but not which person did it.
Emergency changes bypass everything
Under pressure, someone connects directly and fixes it. The change is real, undocumented, and now staging and production disagree.
No record of reads
Change history is often tracked while access to sensitive data is not, even though reading customer records is the more common privacy exposure.
What Migratrix enforces
Authoring a change and approving it are distinct permissions. Configure production stages so a change cannot be approved by the person who wrote it, and require more than one approver where it matters.
Roles are granted per environment rather than globally. The same engineer can hold admin on DEV and read-only on PROD, so day-to-day work does not require standing production rights.
Every change, approval, execution, and rollback is recorded against a named user with a timestamp and environment. The audit log supports an integrity check so you can demonstrate the record has not been altered.
Reviewers see destructive operations, dependency impact, and severity classification next to the change itself, so approval is an informed decision rather than a rubber stamp.
What you can hand an auditor
Common control questions and where the answer comes from.
| Control question | Where Migratrix answers it |
|---|---|
| Are production changes reviewed before deployment? | Approval gates configured per environment, with the approval recorded against the specific change script. |
| Can a developer deploy to production unilaterally? | Environment roles and required approver counts, enforced by the promotion flow rather than by convention. |
| Who accessed customer data, and when? | Explorer reads and writes are logged per user, per environment, including the query that was run. |
| Is there a tested rollback path? | A rollback script is generated alongside each change and stored with it, so recovery does not depend on authoring SQL during an incident. |
| Has the audit record been tampered with? | An audit integrity verification check is available through the platform and the MCP tool surface. |
| Where are database credentials stored? | Encrypted on the Executor host within your network. The platform never receives them. |