vs alternatives

You probably already use one of the tools below. This page is about deciding whether pg-flux replaces it, complements it, or isn't worth the switch.

We try to be honest. Where pg-flux loses, we say so.

#TL;DR matrix

#vs Atlas

Atlas is the closest direct competitor. Both are declarative-schema migration tools. Where they diverge:

When to choose Atlas: you manage multiple DB engines (PG + MySQL), or you want the HCL DSL, or you're on Atlas Cloud already.

When to choose pg-flux: PG-only, you want SQL-as-source-of-truth, you want the codegen layer, you want PG 18 features today.

Use both? Not practically. They'd fight over baseline state.

#vs sqlc

sqlc generates type-safe query code from .sql files. Different problem space.

You should use both. pg-flux handles schema + migration + table-row types. sqlc generates the typed query layer on top.

schema/users.sql ──► pg-flux ──► users table + User struct
                                                ▲
queries/users.sql ──► sqlc ─────────────────────┘
                          │
                          └──► GetUserByID(ctx, id) (User, error)

The handoff is clean because both consume the same SQL schema files. pg-flux owns "how does the schema get there"; sqlc owns "how does the application call it with types".

#vs Prisma

Prisma is full-stack ORM territory. Schema in Prisma DSL, migrations auto-generated, JS/TS-only client.

When to choose Prisma: you want a turnkey ORM with auto-generated client, you're TS-only, you don't need PG-specific features.

When to choose pg-flux: SQL-first team, you want PG superpowers (RLS, partitioning, GIST, range types, etc.), you mix Go and TS.

Use both? Hard. You'd give up Prisma's auto-migrations to use pg-flux's, which removes most of Prisma's value.

#vs Drizzle

Drizzle is a TS-first ORM with a SQL-like query builder. Schema is defined in TS, migrations are SQL.

When to choose Drizzle: you want TS-as-source-of-truth, you want the ORM, you like the SQL-like query syntax.

When to choose pg-flux: you want SQL-as-source-of-truth (the actual SQL syntax, not a JS DSL), you mix Go + TS clients.

Use both? Possible: use pg-flux for the schema + migration + Go types, use Drizzle as the TS client against the same DB. But you'd be defining the schema twice, which defeats the point.

#vs goose / golang-migrate

These are imperative migration runners. You write 001_up.sql / 001_down.sql pairs. They apply them in order.

When to choose goose/golang-migrate: you genuinely want imperative migrations and don't trust generators. You have a tiny schema. You're maintaining a legacy codebase.

When to choose pg-flux: anything else.

Migrating from goose to pg-flux: see Recipes / adoption. Short version: pg-flux dump your live DB, mark all existing migrations as baselined, switch tools.

#vs pg-schema-diff

pg-schema-diff (from Stripe) does exactly what its name says — diffs two PG schemas. Excellent at the diff itself.

When to choose pg-schema-diff: you just need a diff library to embed in your own tool.

When to choose pg-flux: you want the whole product.

These are complementary in spirit: if pg-schema-diff didn't exist, pg-flux's differ would be smaller. We share inspiration.

#vs rolling your own

The default in most projects: a migrations/ folder with hand-written .sql files, applied by psql -f in CI.

This works until it doesn't. The failure modes:

• No drift detection. Someone runs SQL in prod, nobody knows.
• No hazard guards. DROP COLUMN runs and nobody notices.
• No type generation. Your Go and TS drift further from the DB every week.
• No PG version awareness. PG 18 features you wrote work locally but fail in prod (running PG 14).
• No round-trip. Re-creating the dev DB from scratch is hours of manual work.

pg-flux is what you'd build if you tried to write all of that yourself, except we already did.

#When pg-flux is the wrong choice

We try to be straight about this. Don't use pg-flux if:

• You manage MySQL / SQLite / SQL Server. We don't support them. Use Atlas.
• You want a turnkey ORM. We don't generate query code; we generate row types. Pair with sqlc.
• You can't trust generated SQL. Some teams have a policy of human-written-only migrations. pg-flux can still emit the SQL for you to review and commit, but you'll lose the auto-apply guarantees.
• Your schema is genuinely tiny (under 10 tables, no changes for months). The setup cost isn't justified.
• You need migration code (not just SQL) — i.e., per-migration Go functions that do conditional logic. pg-flux migrations are pure SQL. Use a different tool.

For everything else PG-shaped, pg-flux is built for you.

#Decision tree

Do you use PostgreSQL?
├── No  → Atlas (cross-DB), or your engine's native tool
└── Yes
    │
    ├── Do you want declarative SQL as source of truth?
    │   ├── No  → Prisma (TS DSL) / Drizzle (TS code) / Atlas (HCL)
    │   └── Yes
    │       │
    │       ├── Do you also need typed queries (not just typed rows)?
    │       │   ├── Yes → pg-flux + sqlc
    │       │   └── No  → pg-flux alone
    │       │
    │       └── Do you use PG-specific features (RLS, partitions, GIST, range types)?
    │           ├── Yes → pg-flux (others lag here)
    │           └── No  → Either works; pg-flux is still our pick for PG-only shops

If you ended up at "pg-flux," head to quick start.