ForgeSchema Ships Its First Alpha, a Go Engine That Refuses Stale PostgreSQL Migration Plans

ForgeSchema, the studio’s ninth project, is a schema evolution engine for PostgreSQL, written in Go. Its first alpha, 0.1.0-alpha.1, went out on 15 October as a prerelease on GitHub, with command-line binaries for Linux, macOS and Windows on x86-64 and ARM64.

Every Step Written Down

forgeschema inspect takes a read-only snapshot of a PostgreSQL 16 or 17 schema as JSON, and the target is written in YAML. plan compares the two offline and writes out both schemas with a SHA-256 fingerprint for each, then the operations in order, each with its SQL and a plain-language explanation. --explain lays the same plan out as plain text.

Comparing two schemas can’t tell a renamed column from one dropped and another added, so ForgeSchema renames a column only when a separate mapping file says so. Four kinds of change can run: a new table with its primary key and indexes, a column rename, a new nullable column and an ordinary index. A dropped column, a changed type or anything else outside that list comes back with reasons and no SQL, so nothing runs in part.

Checked Before and After

apply runs the saved plan as it is. It locks the tables, reads the catalog again and compares fingerprints, and if the schema’s structure has changed since the plan was made, the plan is refused. The DDL, a check of the new schema and a history record share one transaction: if any step fails before the commit, neither the DDL nor the history record survives. Later, verify compares the database with the target in a read-only snapshot, reports drift with exit code 4 and changes nothing.

CI runs the full suite on PostgreSQL 16.10 and 17.6, including a walkthrough that builds the real CLI and takes a schema holding two synthetic customers through six operations. Both customers keep their values, applying the same plan twice fails, and a column slipped in afterwards is reported as drift. Failure tests cover competing runs, a change committed while apply waits for its locks, timeouts, cancellation, and a history write that fails after the DDL went through, which undoes the DDL. The release workflow built the binaries only after all of it passed. You can step through the recorded runs in the browser demo; it never touches a database.

What the Alpha Leaves Out

Five of the six builds were cross-compiled and haven’t been run on their own platforms, and the macOS and Windows ones aren’t signed. As the capability matrix shows, ForgeSchema handles one schema at a time, with no defaults, foreign keys, or unique and check constraints yet. You have to pause other schema changes while apply runs, and while it holds its locks, the application’s queries on those tables can stall. Anything destructive is later work. So are type conversions and databases other than PostgreSQL.

Like the KeyValueStore tools for Redis and Valkey, ForgeSchema is built for a database people already run. Its code is open source under Apache 2.0.