A database change reaches your approval queue with a migration file and a passing build. You still need to decide whether it fits the change window, which application activity it could block, and what needs to be clarified before you sign off.
That review needs a clear account of the proposed change and its operational impact.
DBLift Enterprise brings pending migrations, impact findings and snapshot context into a report you can inspect and attach to the change record. The developer, DBA and release owner can work from the same artifact when discussing what needs attention before deployment.
Put the consequence next to the change
Consider a request to change a PostgreSQL column from integer to bigint.
The developer's intent is clear: allow a larger range of values. The DBA also needs to assess the effect on the database while that change is applied.
Here is the actual report generated by DBLift Enterprise 5.0.0 for that pending migration:
Open the screenshot at full size · Open the complete report
The report connects V3__widen_integer.sql to the affected table, widen_demo.readings, and flags the impact as an ERROR. It names the ACCESS EXCLUSIVE lock, reports the table-rewrite work, and includes an estimate of approximately 1,000 rows from the captured database state.
Those details give the review a concrete starting point:
| What DBLift shows | What it helps the approver decide |
|---|---|
| The migration file and affected table | Which change to return to the author for clarification or revision |
| ACCESS EXCLUSIVE | Whether the proposed change window can accommodate blocked reads and writes |
| Rewrite work and the snapshot row estimate | What table work needs assessment against the target workload |
| An advisory expand/backfill/contract alternative | Whether to ask the author to assess a staged approach |
The suggested alternative is available for inspection in the report. It still needs review for the application's constraints and deployment process.
Example scope: this report concerns an integer-to-bigint change on PostgreSQL 16.14. Enterprise 5.0.0 can overstate rewrite work for some varchar widenings; the [supporting technical note](https://dblift.com/samples/database-change-approval-evidence/technical-notes.html#known-classification-limit-in-enterprise-500) documents that limit. The row count is a snapshot estimate, and the work category does not predict downtime in seconds.
Give the review a shared reference
A useful approval discussion links the finding to the proposed migration and the database state used to assess it.
The sample report identifies its source snapshot, capture time, pending migration and checksum. That gives the DBA and author a common reference when discussing assumptions or revising the change. Keep the report with the migration revision being reviewed, so the change record retains the evidence used for that decision.
The DBA can then ask a precise question: can the release tolerate this table's blocking lock, or should the author revise the approach? The author can investigate that finding and return an updated plan for review.
This is the value of the artifact: the impact and the change it belongs to are visible together, ready for the approval conversation.
Connect review findings to the release process
DBLift Enterprise also lets a team choose the severity threshold that fails the plan command.
In this example, `--fail-on error` returned exit code 1 because of the impact finding. A CI job configured to honour that result can prevent the change from advancing while the team reviews it. The report remains available to explain the failure.
The same report shows SQL RULES: PASS alongside the overall FAIL. A script can pass the configured SQL checks and still have an operational impact that requires attention. The approver can see which finding caused the plan to fail.
Planning left the pending migration unapplied. The sample's REPLAYED: 0 also makes clear that this report contains analysis against a snapshot, without a completed replay. The team keeps responsibility for approval and for the additional checks its release requires.
Inspect the evidence before evaluating the workflow
The sample Enterprise plan report is an actual generated artifact from the released product. It shows the pending change, the finding that failed the plan, and the information available to the reviewer. A matching JSON report is available for structured inspection.
This sample comes from DBLift Enterprise’s paid planning workflow.
[Review the sample DBLift Enterprise plan](https://dblift.com/samples/database-change-approval-evidence/enterprise-5.0.0-integer-plan.html) and consider what evidence your team would need before approving the same change.