PostgreSQL has a rich ecosystem of extensions—versioned, installable components that extend the database engine itself. Extensions have enabled powerful capabilities such as custom data types, operators, and index methods, and they remain a cornerstone of the PostgreSQL ecosystem.
But application developers face a different problem.
They want to share and reuse application-level PostgreSQL logic: schemas, tables, functions, row-level security policies, and triggers written in pure SQL. While PostgreSQL provides excellent primitives, there has never been a standard, application-layer workflow to publish, install, test, and version this kind of reusable database logic.
PostgreSQL extensions have historically been the primary first-class mechanism for packaging database functionality. While they are well-suited for system-level features, extensions are often constrained or selectively supported on managed PostgreSQL services, making them a poor fit for sharing application-layer SQL across environments.
pgpm addresses this gap.
It brings modular packaging, dependency management, and versioned distribution to application-level PostgreSQL code—giving developers a first-class way to package, test, and reuse database logic as part of their normal development workflow.
The Reuse Problem in Database Development
In application development, reuse is fundamental. Developers compose systems from packages—declaring dependencies, resolving version constraints, and relying on tooling to install components in the correct order. This modularity accelerates development and enables entire ecosystems of shared building blocks.
Database development has historically lacked this layer. Most teams still manage database changes as linear migration files—often copied between projects, with limited reuse, weak dependency modeling, and no standard way to publish tested schema modules a...
