Postgres Summit US2026

Every other part of your application stack lets you edit the end state and figures out the path. Your database makes you write the path and accept whatever schema falls out. That inversion is the source of most migration pain: dependency chains you write by hand, PRs full of DROP/CREATE noise, autogenerated migrations you can't fully trust. This talk presents a schema-first workflow for PostgreSQL: maintain your schema as plain SQL files describing the desired state, and let Postgres itself compute the diff. Apply your files to a temporary "shadow" database, read the result back through the system catalogs, and you have a structured, queryable picture of your schema — including the dependency graph between objects. PostgreSQL already knows that a view depends on a function which depends on a type. You just have to ask it. We'll cover what pg_catalog and pg_depend actually give you, how to turn a dependency graph into a deterministic migration, where the catalog has blind spots (function bodies, implicit sequences, extension-owned objects), and how to keep production migrations explicit and reviewable. The same engine catches drift against production and validates migrations in CI. I'll demo the workflow live. You'll leave with concrete catalog queries you can borrow and a clearer mental model of how Postgres tracks schema dependencies.