PostgreSQL cuenta con un ecosistema muy rico de extensiones: componentes versionados e instalables que amplían el propio motor de la base de datos. Gracias a ellas, PostgreSQL ha incorporado capacidades avanzadas como tipos de datos personalizados, operadores e índices especializados, convirtiéndose en uno de los pilares del ecosistema PostgreSQL.

Sin embargo, los desarrolladores de aplicaciones se enfrentan a un problema distinto.

Ellos necesitan compartir y reutilizar lógica de base de datos a nivel de aplicación: esquemas, tablas, funciones, políticas de seguridad a nivel de registro  y triggers escritos en SQL puro. Aunque PostgreSQL ofrece primitivas excelentes, nunca ha existido un flujo de trabajo estándar en la capa de aplicación para publicar, instalar, probar y versionar este tipo de lógica reutilizable.

Históricamente, las extensiones de PostgreSQL han sido el mecanismo principal para empaquetar funcionalidad de base de datos. No obstante, aunque funcionan muy bien para características de bajo nivel del sistema, suelen estar limitadas o parcialmente soportadas en servicios PostgreSQL gestionados, lo que las convierte en una mala opción para compartir SQL de aplicación entre distintos entornos.

Aquí es donde entra pgpm.

pgpm cubre este vacío aportando empaquetado modular, gestión de dependencias y distribución versionada para código PostgreSQL a nivel de aplicación. De este modo, los desarrolladores disponen de una forma “de primera clase” de empaquetar, probar y reutilizar lógica de base de datos como parte natural de su flujo de desarrollo.

El problema de la reutilización en el desarrollo de bases de datos

En el desarrollo de aplicaciones, la reutilización es fundamental. Los desarrolladores construyen sistemas a partir de paquetes: declaran dependencias, resuelven restricciones de versión y confían en herramientas que instalan los componentes en el orden correcto. Esta modularidad acelera el desarrollo y permite la creación de ecosistemas completos de bloques reutilizables.

El desarrollo de bases de datos, en cambio, históricamente ha carecido de esta capa. La mayoría de los equipos siguen gestionando los cambios mediante migraciones lineales, a menudo copiadas entre proyectos, con poca reutilización, modelado débil de dependencias y sin un estándar para publicar módulos de esquema probados como unidades instalables.

pgpm introduce esta capa en el desarrollo de bases de datos. No reemplaza las migraciones: las organiza en módulos reutilizables y versionados, con dependencias explícitas.

Módulos en la capa de aplicación

pgpm opera en la capa de aplicación, donde los desarrolladores definen esquemas, tablas, funciones, políticas y otra lógica directamente en SQL. Es la capa donde se expresa el comportamiento de la aplicación, no donde se extiende el motor interno de PostgreSQL.

Greg Kemnitz, quien fue Programador Jefe del proyecto Postgres original en la Universidad de California en Berkeley y trabajó en su implementación inicial junto a Michael Stonebraker, lo resume así:

«Lo que hace pgpm no es gestionar extensiones; es modularidad a nivel de aplicación para Postgres. Y esa distinción es importante, porque permite a los desarrolladores pensar en su base de datos igual que en su aplicación: como bloques componibles e instalables.»

Dado que los módulos de pgpm están escritos en SQL puro, se ejecutan con permisos estándar de base de datos y no requieren compilación ni acceso de superusuario. Esto permite desplegarlos de forma consistente en entornos locales, pipelines de CI y servicios PostgreSQL gestionados, facilitando su reutilización entre equipos y plataformas.

Cuando los modelos de implementación tradicionales lo requieren, estos mismos módulos pueden empaquetarse como extensiones nativas de PostgreSQL, sin modificar el diseño a nivel de aplicación.

Workspaces y módulos

pgpm organiza el desarrollo alrededor de workspaces que contienen múltiples módulos relacionados. Un workspace ofrece configuración compartida y una estructura clara para componer módulos, mientras que cada módulo es autocontenido, con sus propias migraciones, dependencias y versiones.

Esta estructura fomenta módulos pequeños y bien definidos, y hace explícitas las relaciones de dependencia. Durante la implementación o las pruebas, pgpm analiza el workspace, construye el grafo completo de dependencias y aplica los cambios automáticamente en el orden correcto. El resultado es un flujo de trabajo que promueve el diseño modular y el desarrollo guiado por pruebas desde el primer momento.

¿Qué hace exactamente pgpm?

pgpm es un gestor de paquetes para PostgreSQL que administra módulos de base de datos: paquetes autocontenidos de esquemas, tablas, funciones, políticas y triggers.

Características clave:

• Los módulos declaran las dependencias de forma explícita: pgpm resuelve los gráficos de dependencias aplicando los cambios en el orden adecuado.
• Cambios reversibles: cada migración incluye scripts de implementación, reversión y verificación.
• Los módulos se distribuyen a través de npm: npm se utiliza como registro de artefactos para módulos SQL versionados.
• Portabilidad por defecto: los módulos funcionan con permisos estándar y se implementan de forma consistente en entornos locales, CI y PostgreSQL gestionado.
• Plantillas estructuradas: pgpm ofrece una organización coherente de workspaces y diseño de módulos, permitiendo a los desarrolladores arrancar proyectos rápidamente con flujos modulares y orientados a pruebas.
• Testabilidad de primera clase: los módulos están diseñados para pruebas end-to-end contra PostgreSQL real, incluyendo la validación de políticas RLS dentro de los flujos normales de desarrollo y CI.

Pruebas e implementación

pgpm fomenta un enfoque de desarrollo de bases de datos guiado por pruebas, utilizando instancias reales de PostgreSQL. Los workspaces pueden incluir flujos de CI/CD por defecto, facilitando la creación de bases de datos efímeras, la instalación de módulos versionados, la ejecución de pruebas de integración y su eliminación automática. El motor de pruebas subyacente es pgsql-test.

Este enfoque trata esquemas, políticas RLS, funciones y triggers como unidades comprobables, no como simples mocks, y funciona de forma consistente en desarrollo local, CI y entornos específicos de cada plataforma.

Filosofía de diseño

pgpm se inspira en Sqitch, de David Wheeler, y se basa en su formato de archivos y flujo de trabajo: SQL puro, sin frameworks y con cambios legibles por humanos. A partir de ahí, extiende estas ideas más allá de proyectos individuales hacia un sistema de empaquetado modular en la capa de aplicación de PostgreSQL. La extensión clave es la composición recursiva: los módulos pueden depender de otros módulos, y pgpm resuelve y despliega todo el grafo de dependencias de forma determinista. Al mantenerse cercano a PostgreSQL y evitar abstracciones tipo ORM, pgpm permite a los desarrolladores trabajar directamente con la base de datos.

Esta base ha demostrado ser flexible en distintos escenarios del ecosistema PostgreSQL: desde empaquetar plataformas backend completas como Supabase para pruebas aisladas sobre infraestructura real, hasta la integración limpia con ORMs modernos orientados al desarrollador como Drizzle. Donde pgpm da un paso más es en tratar los esquemas PostgreSQL como unidades modulares y componibles, con instalaciones deterministas, resolución de dependencias y pruebas de primer nivel.

Primeros pasos

pgpm es software open source y está disponible a través de npm.

• Sitio del proyecto: pgpm
• Documentación y tutoriales: constructive.io/learn

El ecosistema PostgreSQL siempre se ha beneficiado del conocimiento compartido y de los componentes reutilizables. pgpm busca facilitar ese intercambio en la capa de aplicación, para que la próxima vez que construyas algo útil, puedas empaquetarlo y compartirlo con otros.

A medida que más equipos adopten patrones modulares, el ecosistema crecerá de forma acumulativa: esquemas de autenticación compartidos, políticas RLS probadas, módulos de auditoría listos para usar. El objetivo a largo plazo no es solo contar con mejores herramientas, sino con una infraestructura compartida que haga las aplicaciones PostgreSQL más fáciles de construir y mantener.