PostgreSQL · Schema MigrationYour app ships through CI/CD. Your Postgres schema ships from psql.
The schema change is the one release step that skips CI/CD — a developer runs ALTER TABLE straight at production, no review, no staging, no record, and once it's committed, no undo. The DDL was never the hard part; the pipeline around it is. Bytebase puts Postgres change on the same pipeline as your code: every change reviewed, staged, approved, and audited — from a Git pull request or the Bytebase UI.
Teams assemble the pipeline by hand, and every piece carries a cost:
Raw psql and \i
A script applied by hand. Nothing records that it ran, nothing stops it running twice, nothing reviews it first.
A migration runner alone
Flyway or Liquibase tracks versions and applies in order — but it doesn't review the SQL, gate production behind approval, or promote across environments. That's the CI you still wire yourself.
Many tenants, one change
Database-per-tenant means a single schema change has to land on every tenant database — the same way, every time. By hand that's a psql loop over dozens to thousands of databases, and the run that times out halfway leaves some tenants migrated and some not.
Environments drift
Dev, staging, and prod diverge the moment one change lands outside the pipeline. Without drift detection, you find out at the next deploy.
Schema migration in Bytebase
Every change runs the same path.
A change starts as a Git pull request or in the Bytebase UI — and from there the path is one, the same across community Postgres, RDS, Aurora, Cloud SQL, and AlloyDB.
Validate
SQL review runs on the change before it applies — 200+ rules catch unsafe operations, missing indexes, and naming violations. The ruleset is strict on production, relaxed on dev.
Promote
The migration applies in dev, then staging, then production — and across a whole database group in one rollout, not a psql loop over every database. The same script meets progressively more realistic data. A failure stops the chain.
Approve
Approval gates sit between stages. Routine changes auto-promote into dev; production-bound DDL waits for a human who sees the SQL, the review results, and the rollout plan in one record.
Record
Every applied migration is logged with version, environment, executor, and timestamp. Schemas are compared automatically, and a change made outside the pipeline triggers a drift alert.
The migration script is the same in every environment. What changes is the gate in front of each.
What review catches
The unsafe migration, caught before it runs.
A developer adds a nullable column and a partial index to a 12M-row table. SQL review reads it before anything runs:
-- V042__add_user_email_verified.sql
ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT NULL;
CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_users_email_verified
ON users (email_verified) WHERE email_verified = FALSE;
-- ⚠ SQL review (production ruleset)
-- • CREATE INDEX at ~12M rows ≈ 10 min — schedule a low-traffic window
-- • CONCURRENTLY can't run in a txn — mark this migration non-transactionalThe same script promotes through dev and staging before a human approves it for production. Each environment keeps its own audit trail.
What the pipeline gates
Planned schema change — and it says so.
The pipeline gates one class of work, and gates it well: planned schema change. Emergency hotfixes, one-off data patches, and an ANALYZE during an incident don't arrive as a reviewed change — and forcing them through the pipeline only teaches people to route around it.
PostgreSQL schema migration questions
Common questions.
- Does PostgreSQL have built-in schema migration or versioning?
- No database does, really — versioning is a tool's job, not a database's. Postgres runs whatever SQL it receives without recording which migrations ran, enforcing an order, or reviewing a change first, and that's correct behavior for a database. The process around it comes from a migration tool like Flyway or Liquibase, or a pipeline platform like Bytebase that adds review, promotion, and audit on top.
- Doesn't Postgres' transactional DDL make migrations safe already?
- Transactional DDL is a real advantage — most failed migrations roll back cleanly, unlike MySQL or Oracle. But it doesn't review the SQL, gate production behind approval, promote across environments, or catch drift. And CREATE INDEX CONCURRENTLY can't run in a transaction, so the one statement most likely to lock a large table is also the one transactions don't cover.
- How is this different from running Flyway or Liquibase in CI?
- Flyway and Liquibase apply migrations from a changelog and track versions; you still wire SQL review, approval gates, stage promotion, and drift detection around them. Bytebase ships those built in — 200+ review rules, per-stage approval, automatic drift alerts — as a single binary with a web UI. They overlap on the runner and differ on everything above it.
- Which PostgreSQL flavors are supported?
- Any Postgres Bytebase can connect to — community, RDS, Aurora, Cloud SQL, AlloyDB, managed forks. The pipeline runs in front of the database, so there's no extension or superuser requirement on the cluster.
- Can it roll back a migration?
- Postgres rolls back a failed transactional migration on its own. For a change already applied, the reversal runs as its own migration — reviewed, promoted, and audited like any other, not an untracked psql session.