Case Studies on ForgeSchema.com

Adding a Foreign Key to a Legacy Orders Table Full of Orphan Rows

Sun, 18 Oct 2026 00:00:00 +0000

This one comes up whenever an old application gets a second look. The orders table has a customer_id column. It has always pointed at customers.id. Nobody ever declared that as a foreign key, because the original developer said the app handles it.

The app mostly did. Over the years a few customers were deleted by hand, a data import skipped some rows, and now a handful of orders point at customers that don’t exist. Nobody knows how many.

Adding a Required Column to a Busy PostgreSQL Table and What Happens to Old Rows

Sun, 18 Oct 2026 00:00:00 +0000

An online shop wants three new columns on orders. A status that every order must have. A fulfilled_at timestamp. And a public_id uuid to show customers instead of the internal key. All three are NOT NULL. The table has years of orders in it.

On paper that’s three ADD COLUMN lines. In practice each one does something different to the rows already there, and the difference between them is a lock that lasts a millisecond or one that lasts as long as it takes to rewrite the whole table.

Adding a Unique Email Constraint to a Customers Table That Already Has Duplicates

Sun, 18 Oct 2026 00:00:00 +0000

Here’s a scenario almost every product team hits sooner or later. Sign-up has been running for two years. Somebody finally notices that customers.email was never unique, and the login code quietly picks whichever row comes back first. The fix looks like one line of YAML.

unique:
- name: customers_email_key
  columns: [email]

The line is easy. The data is the problem. Two years of sign-ups almost certainly left a few duplicates behind, maybe a user who registered twice, maybe a test account copied from staging. You won’t know until PostgreSQL tries to build the constraint.

Building an Index on a Large PostgreSQL Table Without Freezing the Rest of the App

Sun, 18 Oct 2026 00:00:00 +0000

Reporting is slow. The query behind the monthly dashboard filters events by account and date, and events is by far the biggest table in the database. Everyone agrees it needs an index. Nobody wants to be the one who runs it.

The fear is reasonable. An ordinary CREATE INDEX blocks writes to the table while it builds, and a migration that holds an exclusive lock blocks reads too. On a big table that can take a while. Lock every table in the schema for the length of the migration, as ForgeSchema’s own first alpha did, and the whole app stalls for a reporting index.

Catching PostgreSQL Schema Drift in CI With ForgeSchema Verify

Sun, 18 Oct 2026 00:00:00 +0000

Picture a team with three environments: development, staging and production. The schema lives in a YAML file in the repository, and everyone agrees that file is the truth. Six months in, nobody is quite sure it still is.

Staging got an extra index during a load test. Production has a column someone added from a SQL console during an incident. Development was rebuilt from scratch last week and is probably fine. Nobody wrote any of this down.

How ForgeSchema Blocks an Accidental Column Drop From a Bad Merge

Sun, 18 Oct 2026 00:00:00 +0000

Two branches both touched schema/app.yaml. One added a phone column to customers. The other moved a few columns around for readability. Git resolved the conflict, the build was green, and the merged file was missing billing_address. Nobody noticed. YAML diffs of moved blocks are hard to read.

With a tool that turns a diff straight into SQL, the next deploy runs DROP COLUMN billing_address. The column and every value in it are gone, and the first sign is a support ticket about invoices.

Renaming a PostgreSQL Column Without Losing Data in ForgeSchema

Sun, 18 Oct 2026 00:00:00 +0000

A small team is tidying up an old schema. The customers table has a column called customer_name, which is redundant inside a table called customers. They want full_name. They edit the YAML, swap the name, and run a diff.

Most diff-based migration tools see exactly what you’d expect from text. One column disappeared, another appeared. The cheap way to get from one to the other is drop and add, and the cheap way deletes every name in the table.

Why ForgeSchema Refuses a Migration Plan Made Stale by an Overnight Hotfix

Sun, 18 Oct 2026 00:00:00 +0000

Monday afternoon, a developer builds a migration plan. It adds a notes column to customers and an index on it. Two colleagues review it, approve it, and it’s scheduled for Wednesday’s maintenance window.

Tuesday night there’s an incident. Someone on call adds a column to customers by hand to unblock a hotfix. It works, everyone goes to bed, and the plan sitting in the deploy queue still describes Monday’s database.