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.
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 as installable units.
pgpm brings this layer to database development. It doesn't replace migrations—it organizes them into reusable, versioned modules with explicit dependencies.
pgpm operates at the application layer, where developers define schemas, tables, functions, policies, and other database logic directly in SQL. This is the layer where application behavior is expressed, rather than where the database engine itself is extended.
Greg Kemnitz, who served as Chief Programmer on the original Postgres project at UC Berkeley and worked on the original implementation with Michael Stonebraker, put it this way:
"What pgpm is doing isn't extension management—it's application-level modularity for Postgres. That distinction matters, because it lets developers think about their database the same way they think about their application: as composable, installable building blocks."
Because pgpm modules are written in pure SQL, they run with standard database permissions and do not require compilation or superuser access. They can be deployed consistently across local development, CI, and managed Postgres environments, making them practical to share and reuse across teams and platforms.
When traditional deployment models require it, the same modules can also be packaged as native PostgreSQL extensions—without changing the underlying application-level design.
pgpm organizes database development around workspaces that contain multiple related modules. A workspace provides shared configuration and a clear structure for composing modules together, while each module remains self-contained with its own migrations, dependencies, and version.
This structure encourages small, focused modules and makes dependency relationships explicit. When deploying or testing, pgpm scans the workspace, builds the full dependency graph across modules, and applies changes in the correct order automatically. This workflow promotes modular design and enables test-driven development against real PostgreSQL from the start.
pgpm is a package manager for PostgreSQL that manages database modules—self-contained packages of schemas, tables, functions, policies, and triggers.
Key characteristics:
pgpm encourages end-to-end, test-driven database development against real PostgreSQL instances. Workspaces can include CI/CD workflows by default, making it straightforward to spin up ephemeral databases, install versioned modules, run integration tests, and tear them down automatically. The underlying test harness is provided by pgsql-test.
This approach treats schemas, RLS policies, functions, and triggers as testable units rather than mocks, and works consistently across local development, CI, and platform-specific workflows.
pgpm draws inspiration from David Wheeler’s Sqitch and builds around its file format and workflow—framework-free, pure SQL, and human-readable change files—while extending those ideas beyond individual projects into a modular, application-layer packaging system for PostgreSQL. The key extension is recursive composition: modules can depend on other modules, and pgpm resolves and deploys the full dependency graph deterministically. By staying low-level and Postgres-native, pgpm keeps developers close to the database without introducing an ORM abstraction.
This foundation has proven adaptable across very different parts of the PostgreSQL ecosystem, from packaging full backend platforms such as Supabase for isolated testing against real infrastructure to integrating cleanly with developer-first ORMs like Drizzle. Where pgpm extends these ideas is in treating PostgreSQL schemas as modular, composable units with deterministic installs, dependency resolution, and first-class testing.
pgpm is open source and available via npm.
The PostgreSQL ecosystem has long benefited from shared knowledge and reusable components. pgpm aims to make that sharing easier at the application layer—so the next time you build something useful, you can package it for others to use.
As more teams adopt modular patterns, the ecosystem compounds: shared authentication schemas, tested RLS policies, auditing modules that work out of the box. One long-term goal is not just better tooling, but shared infrastructure that makes PostgreSQL applications easier to build and maintain.