pglifecycle 2.0 has entered public beta, offering PostgreSQL teams an open source way to keep schema definitions in version control as structured YAML rather than reconstructing them from years of migration files. Each table, view, function, role and other object gets its own file, so the current schema stays browsable and reviewable. The project is a Rust rewrite of an earlier tool that has managed AWeber's production schema for more than seven years.
The beta expands PostgreSQL object coverage and improves deployment convergence and safety.
- Schema projects: pull an existing database into a YAML project, one object per file
- Archive builds: compile a project into an archive suitable for
pg_restore - Diffing: compare a project against a live database and generate the DDL needed to reconcile them
- Plan-first deployment: destructive changes are withheld unless explicitly allowed, so generated SQL is safe to review in CI
- GitHub Action: the companion
pglifecycleAction detects schema drift and posts deployment plans to pull requests without applying them - Rust rewrite: version 2 reimplements the original tool in Rust
For developers, the interesting shift is workflow rather than raw feature count. Treating schema as reviewable files means diffs appear in pull requests alongside application code, and the plan-first model means a CI job can show exactly which statements a deployment would run — and refuse the destructive ones — before anything touches a database. Because the tool targets standard PostgreSQL objects and emits pg_restore-compatible archives, it can sit alongside existing backup and migration pipelines instead of replacing them outright. The maintainers explicitly invite real-world test cases during the beta, so teams with complex schemas have a chance to influence coverage before a stable release.
Source: https://www.postgresql.org/about/news/introducing-pglifecycle-20-beta-3401/