Development on ForgeSchema.com

Introducing ForgeSchema

Thu, 15 Oct 2026 09:30:00 +0300

A schema change is easy to describe casually and surprisingly difficult to execute reliably. A renamed column can look like a deletion followed by an addition. A new requirement can conflict with existing rows. A migration prepared yesterday can be wrong for a database changed this morning. ForgeSchema is being built to make those differences explicit before a change is applied.

The engine inspects PostgreSQL, compares current structure with a desired YAML schema, generates an explained migration artifact, applies supported changes transactionally and verifies the target independently. Explicit renames preserve intent; unsupported changes block the entire plan.

ForgeSchema alpha release with portable CLI binaries

Thu, 15 Oct 2026 12:00:00 +0300

ForgeSchema v0.1.0-alpha.1 packages the inspect, plan, apply and verify command workflow as downloadable CLI binaries. The download page provides Linux, macOS and Windows archives for x86-64 and ARM64, with SHA-256 checksums, Apache 2.0 licensing and third-party attribution.

The release pipeline runs the PostgreSQL 16.10/17.6 suites and disposable customer walkthroughs, then builds all six archives. It smoke-tests the Linux x86-64 executable before publication. Other platforms are cross-compiled rather than native-runtime tested; macOS and Windows binaries are unsigned and not notarized.

Explore ForgeSchema in the browser

Thu, 15 Oct 2026 11:08:00 +0300

The browser demo lets you explore the completed prototype without setting up a database. Choose PostgreSQL 16.10 or 17.6, compare the recorded before/after schemas, open each of the six explained SQL operations and examine the preserved customer records.

The verification view switches between a matching target and the same schema with an unexpected external_note column. The report shows one structural difference. Verification leaves that change untouched; the walkthrough harness later removes its own injected column and verifies the target again.

Session 6: reproducible prototype and handoff

Thu, 15 Oct 2026 10:55:00 +0300

The final checkpoint delivers a reproducible customer-database walkthrough, complete command documentation and a supported/unsupported feature matrix. All six planned sessions are complete.

Fresh CI checkouts ran the compiled CLI on PostgreSQL 16.10 and 17.6. Both walkthroughs applied six operations, preserved both synthetic customer rows, independently verified the target, rejected stale replay and detected injected drift without repair. The harness cleaned up only its isolated schema; migration history remained until disposable database teardown.

Checking the Database Without Changing It

Thu, 15 Oct 2026 10:30:00 +0300

ForgeSchema now has an independent verify command. It compares a live PostgreSQL schema with a desired schema file or a reviewed plan’s target, then reports a match or structured drift. It reads catalog metadata in a read-only snapshot and makes no repairs.

That distinction matters after deployment. A database may have reached the expected structure and then changed again. Verification identifies missing or unexpected objects, type and nullability changes, and ordered key or index differences. It does not guess that two different column names represent a rename, and it does not turn a difference into executable SQL.

Executing the Reviewed Plan as One Transaction

Thu, 15 Oct 2026 10:10:00 +0300

ForgeSchema can now execute a reviewed migration artifact. The new apply command does not recalculate the desired migration against whatever it happens to find. It validates the saved plan, freezes a private copy and checks that the live database still matches the source the reviewer saw.

The order of that check is important. Another transaction may hold a table lock while changing its structure. ForgeSchema waits for the locks first, then reads fresh catalog metadata before deciding whether the reviewed starting conditions still hold. The tests include exactly that case: an outside transaction commits a change during the wait, and the stale plan is rejected.

A Migration Plan You Can Read Before It Runs

Thu, 15 Oct 2026 09:53:00 +0300

ForgeSchema now turns the difference between an observed schema and a desired schema into a reviewable plan. The artifact contains both complete descriptions, their fingerprints, explicit rename instructions and an ordered set of generated statements. It is deterministic: the same supported inputs produce the same plan.

Rename intent is the key distinction. Removing customer_name and adding full_name does not prove that the two columns hold the same information. A separate mapping tells the planner that this is a rename, allowing it to account for the existing key and index references that PostgreSQL updates along with the column. Without that instruction, the destructive interpretation is blocked.

Reading PostgreSQL Without Losing the Details

Thu, 15 Oct 2026 09:40:00 +0300

The second ForgeSchema checkpoint connects the schema contract to an existing PostgreSQL database. The inspect command reads catalog metadata in a read-only transaction and returns the same canonical representation used by the YAML validator. Repeated inspections of a supported unchanged schema produce identical output.

The difficult part is deciding what the engine can describe faithfully. A column default, a partial index or a generated expression cannot simply disappear from the snapshot. The inspector rejects unsupported structures explicitly, identifying the object that prevents a complete supported snapshot. It also separates primary key backing indexes from ordinary indexes and preserves the order of columns within composite keys.

The Schema Foundation Is in Place

Thu, 15 Oct 2026 09:30:00 +0300

The first ForgeSchema development session establishes the input contract for the engine. A versioned YAML file describes one PostgreSQL schema, its tables, columns, basic primary keys and ordinary indexes. The validator checks names, types and references, then produces canonical JSON with stable ordering.

This checkpoint includes a Go command line program, examples, automated validation tests and a populated PostgreSQL fixture for subsequent work. Schema fingerprints are available in the Go package; they identify canonical representations and are not a security signature.