If you've worked with Postgres long enough, you've seen the pattern: teams reinventing the wheel, copying SQL between projects, manually tracking dependencies, and hoping their migrations deploy in the right order. Schemas, Row-Level Security policies, multi-tenant architectures—the kind of work that sits at the foundation of every serious application—gets rebuilt from scratch, project after project.
Meanwhile, application developers have had modularity for years—install a package with a single command, let the package manager handle the hard parts. But the developer experience for databases? It hasn't really changed much since I started in 2005.
Today, we're announcing pgpm—and with it, a new category: Modular Postgres.
We're Defining a New Category
This isn't incremental improvement. We're not building another migration tool or extension manager. We're defining something fundamentally new: application-layer modularity for Postgres.
Extensions have made Postgres what it is—custom data types, operators, index methods, and more. They extend the database engine itself, and they're essential.
But application developers need something different. We need to share schemas, RLS policies, functions, and triggers across projects—application-level logic written in pure SQL. Extensions weren't designed for this. They often require compilation and superuser privileges, and managed providers frequently restrict them. That makes extensions a poor vehicle for shipping reusable SQL for apps.
Until now, there's been no first-class way to publish, version, and install application-level database logic as reusable modules.
pgpm fills that gap. It operates at the application layer, where you write pure SQL with standard permissions. Modules deploy consistently across local development, CI, and production—wherever you run Postgres.
Greg Kemnitz, who served as Chief Programmer of the Postgres Project at UC Berkeley and worked on the original Postgres 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."
That's the shift. Your database isn't a monolithic migration chain anymore—it's a composition of focused, testable modules with explicit dependencies and clear boundaries.
The Problem We're Solving
Modern applications demand sophisticated database architectures: multi-tenant schemas, audit logging, access control, domain-specific business logic. Traditionally, teams manage this complexity in a single migration chain—thousands of lines of SQL with implicit dependencies, no clear ownership boundaries, and no way to test components in isolation.
When you want to reuse a schema across projects, you copy-paste SQL files and lose all version history. When modules depend on each other, you manually track what needs to deploy first. When something breaks, you trace through a tangled web of migrations to find the root cause.
This doesn't scale. And with AI-assisted development accelerating the pace of change, the risks compound. Databases are being deployed with serious oversights—some of which have already resulted in published CVEs. Teams are moving fast without guardrails, and it's creating avoidable risks.
What Modular Postgres Actually Means
pgpm brings the composability developers expect from modern ecosystems to Postgres. Build a module once, publish it, and let anyone install and test it with a single command.
Here's what that looks like in practice:
Separation of Concerns. Decompose complex databases into focused modules—authentication, auditing, billing—each with its own schema, migrations, and test suite. Clear boundaries. Clear ownership.
Explicit Dependencies. Modules declare what they depend on. pgpm builds the dependency graph, resolves topological order, and deploys everything in the correct sequence automatically. No manual orchestration.
Pure SQL, Standard Permissions. Modules are written in SQL and run with standard database permissions. No compilation, no superuser required. Deploy consistently across local development, CI, and managed Postgres environments.
First-Class Testing. Test modules against real Postgres—not mocks. Spin up ephemeral databases, deploy your modules, run tests, tear down automatically. Validate your RLS policies before they reach production. The underlying test harness is powered by pgsql-test.
npm Distribution. Publish and install database modules across projects with a single command. The same workflow JavaScript developers have had for years, now for Postgres.
Workspaces and Modules
pgpm organizes database development around workspaces that contain multiple related modules. Think of a workspace like an npm monorepo, and modules like the individual packages inside it. Each module is self-contained with its own migrations, dependencies, and version—but they compose together under shared configuration.
This structure encourages small, focused modules and makes dependency relationships explicit. When you deploy, pgpm scans your workspace, builds the full dependency graph across modules, and applies changes in the correct order automatically. You never manually specify deployment order. The same workflow promotes test-driven development against real Postgres from the start—spin up an ephemeral database, deploy your modules, run your tests, tear it down.
Workspaces provide a structured starting point that encourages modular design from day one. Instead of starting with a monolithic migration chain and hoping to refactor later, you begin with clear boundaries and composable pieces.
Built on Proven Foundations
pgpm draws inspiration from David Wheeler's Sqitch—framework-free, pure SQL migrations written by developers, not generated by an ORM. We loved Sqitch's philosophy: human-readable change files, clear project structure, and full control over your database logic.
Where pgpm extends these ideas is in bringing true modularity to database development. pgpm is TypeScript-native, designed for the npm ecosystem from the ground up. This architectural choice unlocks the publish/install workflow that makes modularity possible. Modules can depend on other modules, and pgpm resolves and deploys the full dependency graph deterministically. By staying low-level and Postgres-native, we keep developers close to the database without introducing an ORM abstraction.
The approach has already proven itself. We packaged the entire Supabase Postgres backend as a set of pgpm modules, enabling local and CI testing against real Postgres infrastructure—including end-to-end testing of Row-Level Security policies. The same modular architecture integrates cleanly with modern ORMs like Drizzle, allowing teams to pair type-safe application code with reusable, battle-tested database modules.
The Ecosystem Effect
Individual packages might be small, but the ecosystem effect is transformative. Someone builds a robust audit logging module, publishes it to npm, and everyone can use it. Someone creates a multi-tenant module with Row-Level Security policies, and it becomes a building block for SaaS applications across the community.
For teams building complex systems, this composability compounds. A well-tested audit logging module becomes a foundation for compliance across services. A multi-tenant module with Row-Level Security accelerates SaaS development organization-wide. Instead of copying SQL between projects, teams build on shared, versioned components.
This is the same dynamic that made npm successful for JavaScript. We're bringing it to Postgres.
Key Capabilities
- Application-Layer Modularity: Reusable schemas, functions, RLS policies, and triggers in pure SQL
- Automatic Dependency Resolution: Explicit dependencies with deterministic deployment order
- Idempotent, Reversible Migrations: Deploy, revert, and verify scripts ensure safe, reproducible changes
- First-Class CI/CD Testing: Test modules in isolation using ephemeral databases and end-to-end workflows
- TDD-First RLS Validation: Verify Row-Level Security policies against real Postgres before changes reach production—run permission scenarios and validate access control at scale
- npm Distribution: Publish and install database modules with a single command
- Postgres Extension Compatible: Optional dual packaging as native extensions
- Transactional Safety: All deployments run in transactions with automatic rollback on failure
- Lightning Fast: TypeScript-based engine, millisecond deployments
Getting Started
Teams can get started with pgpm in minutes. Initialize a workspace, create modules, install dependencies, and deploy to Postgres using a familiar, package-driven workflow.
For more information, visit pgpm.io.
We've created comprehensive courses to help you get started at constructive.io/learn:
- Quickstart: Getting Up and Running — Get started in minutes with prerequisites and your first deployment
- Modular Postgres Development — Learn workspaces, modules, dependencies, and testing
- Authoring Database Changes — Master the workflow for adding and organizing changes
- End-to-End Postgres Testing — Test your modules with ephemeral databases and CI/CD automation
Building Strong Foundations
At Constructive, we believe software should be built on strong foundations—modular, secure, interoperable, and built to last. pgpm is a core piece of that vision: a digital construction kit for databases, where every component is testable, every dependency is explicit, and every deployment is deterministic.
The Postgres ecosystem has long benefited from shared knowledge and reusable components. pgpm makes that sharing easier at the application layer—so the next time you build something useful, you can package it for others to use.
Modular Postgres is the future of database development. Let's build it together.