DEV.co
Open-Source DevOps · pgplex

pgschema

pgschema is an open-source CLI tool that brings Terraform-style declarative schema migration to PostgreSQL. Instead of writing numbered migration files, you declare the desired schema state in SQL, and pgschema automatically diffs and generates the migration DDL. It handles Postgres-specific objects like row-level security, partitioning, and triggers without requiring a shadow database.

Source: GitHub — github.com/pgplex/pgschema
967
GitHub stars
58
Forks
Go
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorypgplex/pgschema
Ownerpgplex
Primary languageGo
LicenseApache-2.0 — OSI-approved
Stars967
Forks58
Open issues5
Latest releasev1.12.0 (2026-07-06)
Last updated2026-07-08
Sourcehttps://github.com/pgplex/pgschema

What pgschema is

Written in Go, pgschema provides dump/plan/apply workflow for PostgreSQL schema management. It uses an embedded Postgres instance for validation, supports concurrent change detection and transaction-adaptive execution, and covers 14+ schema object types across Postgres versions 14–18. No migration history table or ORM required; schema versioning via plain SQL files.

Quickstart

Get the pgschema source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/pgplex/pgschema.gitcd pgschema# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Teams migrating from manual SQL workflows

Organizations currently managing schema changes through hand-written SQL scripts or ad-hoc migrations can adopt pgschema to introduce version control and automated validation without rewriting their entire CI/CD pipeline.

Complex multi-tenant Postgres deployments requiring Postgres-specific features

Applications leveraging row-level security, custom types, partitioned tables, constraint triggers, or domain types benefit from pgschema's deep Postgres support, which generic tools (Flyway, Liquibase) skip entirely.

Infrastructure-as-code workflows with a plan/preview requirement

Teams already familiar with Terraform's state-based approach and needing a preview step before applying schema changes can adopt pgschema as a natural extension to their GitOps and DevOps workflows.

Implementation considerations

  • Embedded Postgres instance used for validation; ensure build environment has sufficient disk and memory for temporary schema snapshots.
  • Requires explicit schema dump and edit cycle; teams must establish clear ownership and review process for schema.sql changes before applying to production.
  • Concurrent change detection and lock timeout control are built in, but production apply strategy (transaction mode, rollback handling) should be tested in staging first.
  • No migration rollback capability; treat schema.sql as forward-only (similar to Terraform state). Downtime planning for breaking changes (column drops, type changes) is manual.
  • CLI-centric; integration into existing CD pipelines (GitHub Actions, GitLab CI, etc.) requires scripting and environment variable management for credentials.

When to avoid it — and what to weigh

  • Multi-database environments requiring vendor-agnostic tooling — pgschema is Postgres-only. If your organization manages schema migrations across MySQL, SQL Server, Oracle, or other databases, tools like Atlas or Liquibase are better fits.
  • Windows-native deployments without WSL/virtualization — pgschema does not support native Windows; only WSL or Linux VMs are supported. Teams bound to Windows Server or desktop environments will face friction.
  • Regulatory environments requiring formal audit trails and fine-grained access control — pgschema itself provides no built-in audit logging, data masking, or multi-role access controls. Organizations with strict compliance or data governance requirements should evaluate Bytebase or equivalent platforms.
  • Projects requiring long-term commercial support or SLA guarantees — pgschema is community-supported and sponsored by Bytebase as a free offering with no guarantees. Vendors offering paid support tiers (Flyway, Liquibase) may be more appropriate for mission-critical systems.

License & commercial use

Licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license allowing commercial use, modification, and distribution under the terms stated in the license.

Apache-2.0 permits commercial use without restriction. However, pgschema itself is free and community-supported; no commercial support contract is available from the project. Organizations requiring SLAs, dedicated support, or commercial indemnification should seek vendor-backed alternatives or negotiate support separately. Sponsored by Bytebase (a commercial platform), but pgschema has no current monetization model.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityLow
DEV.co fitStrong
Assessment confidenceHigh
Security considerations

pgschema itself does not provide audit logging, role-based access control, or data masking. Credentials passed via environment variables or CLI flags; ensure secrets are not committed to version control or exposed in CI/CD logs. Embedded Postgres instance cleans up after validation, but temporary files should be managed securely in production environments. No formal security audit data provided; assess risk based on use case (non-sensitive schema changes lower risk than sensitive data environments).

Alternatives to consider

Atlas

State-based, multi-database support, covers Postgres features. Requires shadow database by default; free tier available with paid advanced features.

Flyway

Migration-file-based, multi-database, widely adopted. Requires manual migration writing and sequencing; free tier with commercial options.

Liquibase

Migration-file-based, multi-database, large ecosystem. Requires manual sequencing; feature-gated pricing model.

Software development agency

Build on pgschema with DEV.co software developers

Try pgschema today—no shadow database, no migration history tables, just declarative schema management in plain SQL. Perfect for teams already using GitOps and infrastructure-as-code practices.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

pgschema FAQ

Does pgschema require a shadow database?
No. pgschema uses an embedded Postgres instance internally for validation and cleans up after itself, avoiding the infrastructure overhead of tools like Atlas.
Can pgschema handle Postgres-specific features like row-level security and partitioning?
Yes. pgschema auto-detects and diffs RLS policies, partitioned tables, custom types, domains, constraint triggers, and 14+ other Postgres-specific objects. Generic tools like Flyway require manual SQL for these.
Is there a rollback or undo mechanism?
Not mentioned in the documentation. pgschema is forward-only; treat schema.sql as the source of truth. Rollback requires manual downtime planning or a separate restore procedure.
Can pgschema be used in a CI/CD pipeline without manual review?
Yes, via --auto-approve flag. However, the default workflow includes a plan/preview step and manual confirmation, allowing for peer review and approval gates before applying changes.

Software development & web development with DEV.co

Adopting pgschema is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source devops software in production.

Ready to streamline your Postgres schema workflow?

Try pgschema today—no shadow database, no migration history tables, just declarative schema management in plain SQL. Perfect for teams already using GitOps and infrastructure-as-code practices.