# A migration role should not become the application's login

Schema changes may require privileges that ordinary requests do not. Keep that authority scoped to the release process and remove temporary access afterwards.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Identify the required operations

List the tables, schema objects and data changes the migration will perform. Determine the privileges needed for those operations on the actual database platform.

Do not solve a permission failure by making the normal application role an unrestricted owner. That turns a release-time requirement into permanent authority for every request and background task using that identity.

Use a controlled migration identity with a documented owner and execution path. Keep its credentials separate from the runtime application's configuration.

## Review data handling during rehearsal

A production-sized rehearsal does not automatically require unrestricted production data. Use a suitable synthetic or protected dataset while preserving the size and distribution needed to test performance.

If sensitive data is used under an approved process, account for copies in temporary tables, exports, logs and local debugging tools. A migration script can print rejected rows or SQL parameters without the team noticing.

Test error output with synthetic sensitive values. Redaction should cover failure paths as well as normal progress messages.

## Check tenant and policy boundaries

A backfill may intentionally operate across tenants, but that authority should not leak into ordinary application code. Keep the broad operation explicit and audit its selected scope.

For databases with row-level policies, test under the actual migration and runtime roles. Ownership or bypass privileges can change which controls apply. A successful test using a privileged migration identity says little about runtime access.

After the change, verify that the application can perform its intended operations with its normal restricted role. Do not leave it depending on a privileged connection introduced for convenience during migration.

## Close the temporary access path

Remove temporary grants, credentials and diagnostic exports according to the release procedure. Confirm that scheduled jobs do not retain the migration identity after the main deployment ends.

Record who ran the migration, which reviewed version executed and where its outcome can be inspected. Avoid logging secrets or full sensitive records as evidence.

The review is complete when the schema change works and normal operation still uses the intended access boundary. Successful data conversion does not justify leaving a broader privilege model behind.

## Sources

- [PostgreSQL: privileges](https://www.postgresql.org/docs/17/ddl-priv.html)
- [PostgreSQL: row security policies](https://www.postgresql.org/docs/17/ddl-rowsecurity.html)