Database and Migrations

Database changes are production changes. Treat schema, data, backups, and access paths as part of the release system.

Ownership

Every datastore should have:

• Owning service or platform team.
• Business owner for critical data.
• Data classification and retention policy.
• Backup, restore, and disaster recovery expectations.
• Access model for humans and workloads.
• Dashboard and alerts for health, capacity, and replication.

Migration safety

Prefer expand-and-contract migrations.

Safe migrations usually:

• Are backward-compatible with the currently running version.
• Avoid long locks on hot tables.
• Can be retried safely.
• Have clear rollback or forward-fix steps.
• Include verification queries.
• Separate schema changes from risky data rewrites.

Backups and restore

Backups are only useful when restore has been tested.

• Define RTO and RPO per datastore.
• Test restore into an isolated environment.
• Verify application compatibility after restore.
• Document who can initiate restore and who approves it.
• Monitor backup freshness and failure.

Access and security

• Use workload identity or managed credentials where possible.
• Separate read-only, migration, application, and admin access.
• Log privileged access and schema changes.
• Encrypt data at rest and in transit.
• Avoid sharing one database account across many services.

Watchouts

• Shared databases create hidden coupling between teams.
• Manual hotfixes bypass audit and repeatability.
• Data migrations can create irreversible business impact.
• Schema drift between environments invalidates testing.