Perseid 0.1.0 has been released, reviving a familiar approach to managing PostgreSQL schema changes. Announced by maintainer Joe Abbate, Perseid is the successor to Pyrseas, returning after a long hiatus as a set of utilities for versioning database schemas. Rather than tracking migrations as an ordered pile of manual SQL files, Perseid represents the desired schema as YAML and lets you diff and apply changes against a live database.
The tooling is split across two commands that mirror the Pyrseas workflow:
dbtoyamlextracts an existing PostgreSQL schema and writes it out as YAML, giving you a canonical, human-readable snapshot of the current state.yamltodbreads a YAML specification and generates (or applies) the SQL needed to bring a target database into agreement with it.- This initial release covers SQL SCHEMAs, TABLEs, COLUMNs and CONSTRAINTs — the core relational surface, with other object types expected to follow.
- PostgreSQL 17 or higher is required, so older server versions are not supported.
The code lives in a Codeberg Git repository, and documentation is published alongside it on a Codeberg Pages site.
Why this matters: declarative schema management is attractive for teams that want schemas under version control without hand-maintaining long migration chains. By keeping the specification in YAML, yamltodb can compute the delta between the desired state and the actual database, which reduces the risk of drift between environments and makes schema reviews read like ordinary diffs. The trade-offs are real — round-tripping through YAML adds a translation layer, and the initial object coverage stops at schemas, tables, columns and constraints, so indexes, views and other objects still need manual handling. Teams on PostgreSQL 17 can experiment now; those on earlier releases cannot adopt it yet. With Pyrseas heritage and a fresh 0.1.0 baseline, this is a project worth watching as coverage expands.
Source: https://www.postgresql.org/about/news/perseid-010-is-now-available-3405/