Skip to main content

PostgreSQL schema as desired state

`pgpac` is DACPAC for Postgres. Your SQL source is the desired state configuration, Git carries the change history, and `pgpac` computes the diff between that intent and a live database.

Read the quickstartWhy desired state

Desired state in SQL

Your schema files describe what PostgreSQL should look like now.

Git holds the history

Review normal SQL diffs instead of maintaining a migration narrative.

pgpac computes the delta

Build, compare, and apply against the live database only when you are ready.

Workflow

# SQL in Git is the source of truth
pgpac build --project app.pgpac --output out/

# Compare desired state to the live target
pgpac plan --package out/app.pgpkg --connection "postgres://..."

# Apply the reviewed delta
pgpac apply --package out/app.pgpkg --connection "postgres://..."

Keep reasoning in terms of the schema you want. Let `pgpac` reason about the transition.

Stop encoding intent as migration choreography

Migration-heavy workflows force teams to reason about intermediate steps, ordering, and drift repair. `pgpac` shifts the unit of work back to the schema itself: define the desired state in SQL, keep that state in Git, and plan from the target database's current reality.

01

Model the schema you want

Tables, views, functions, types, and security live as source-controlled SQL files.

02

Diff desired state against reality

pgpac inspects the target database and generates an ordered plan from actual drift.

03

Apply with reviewable safety gates

Teams can inspect text, JSON, or SQL output before execution, with destructive changes explicitly gated.

Git is the timeline

The SQL files are the desired schema. History, review, and rollback discussion stay in normal source control where teams already work.

The target database is the comparison point

Plans are produced by comparing the packaged desired state with what PostgreSQL actually contains, not by assuming every migration ran perfectly.

Change execution stays explicit

Build artifacts, inspect the computed plan, and apply with destructive-operation gates when the team intentionally allows them.