Giving back: database changes and honest delivery boundaries
October 3, 2026
Software development at Full Sail helped me connect the systems I operated with the application behavior running on top of them. Database changes are a good example: the application may deploy cleanly while its schema still needs a carefully ordered change.
The PostgreSQL and Flyway lab gives readers a small migration history they can inspect. PostgreSQL lives on a private Compose network, and Flyway applies versioned SQL migrations. The example's initial database identity is intentionally simple for a disposable lab; a real service needs separate roles and reviewed privileges.
History is useful evidence
A migration has an order, content, and a recorded result. Validation can compare the expected migration history and checksums with what Flyway recorded. That is useful, but it is not a complete audit of every live schema change someone might make outside the migration process.
After a migration has been applied, editing the old file can create a mismatch between history and source. Prefer a reviewed corrective migration when that is the appropriate recovery. Reverting a Git commit does not reverse a database's data changes or recover deleted rows.
Backup and restore therefore belong in the delivery design. Know whether a migration is compatible with the running application, how long it may take, and what a failed operation leaves behind. The lab is a starting point for these questions, not a promise that every migration is safely reversible.
Separate ownership without hiding dependencies
Terraform describes infrastructure. Application code builds a service. Kubernetes manifests describe its deployment. Flyway migrations describe database changes. These can be separate repositories with clear owners, but the release still needs to coordinate their dependencies.
Use GitHub Actions and your own runner if GitHub is your platform, or GitLab CI and your own runner if GitLab is your platform. GitLab's Kubernetes agent provides an authorized cluster access path; it is not the migration engine or a universal reconciliation controller. The series guide explains those distinctions.
I want readers to gain a delivery vocabulary that matches what actually happened. That is valuable in SRE and platform work, and just as valuable when an AI application stores conversation context or other state in PostgreSQL.