Project files, metadata, tests, and parameters become session-scoped temporary tables and stable views.
Programmable PostgreSQL deployments
pgmi
Test the deployed database before you commit it. pgmi loads your project into one PostgreSQL session — your deploy.sql selects files, controls transactions, runs database tests, and decides whether to commit.
Execution model
pgmi prepares the session. Your SQL decides the deployment.
deploy.sql queries those views and chooses ordering, filtering, transactions, idempotency, and rollback.
The generated plan runs in the same PostgreSQL session, with notices and errors coming directly from PostgreSQL.
Where it fits
For database work that needs real control.
Use pgmi when deployment logic belongs close to the database: environment-aware changes, test gates, data loads, generated APIs, or application behavior expressed in SQL.
- CLI flags stay focused on infrastructure: connections, parameters, compatibility, observability.
- Deployment behavior stays in
deploy.sql, where it can be reviewed and tested with the rest of the database code. - The advanced template can expose PostgreSQL-backed REST, RPC, and MCP APIs without changing the core model.
Start here
One small scaffold. Then whatever you build on it.
The basic template
A compact migration scaffold: path-based ordering, tests inside the deployment transaction, and a deploy.sql you can read in one sitting. This is the recommended starting point.
Reference app — scaffold and trim
A full SQL-native application built on pgmi: REST, RPC and MCP endpoints, multi-tenant row-level security, audit logging. It exists to show what the model enables — read it, take the parts you need. Either template is production-capable; this one is simply more infrastructure.
See what pgmi enables