using-pgdbm

Create a shared pgdbm pool with schema-isolated managers and template queries.

Updated Jul 28, 2025
One-click install
npx skills add https://github.com/juanre/pgdbm --skill using-pgdbm
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: using-pgdbm
Source: https://github.com/juanre/pgdbm/tree/main/skills/using-pgdbm
Command: npx skills add https://github.com/juanre/pgdbm --skill using-pgdbm

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This skill clarifies how to design and operate a scalable pgdbm setup using one shared pool and per-service schemas, including template-based queries and per-module migrations.

Core Features & Use Cases

  • ONE pool to rule them all: centralized connection management to minimize database load.
  • Schema isolation: each service/module operates in its own PostgreSQL schema for safe multi-tenancy.
  • Template-driven queries: {{tables.*}} syntax ensures portability across deployment modes.
  • Migrations per module: run migrations independently for each service while sharing the pool.
  • Production patterns: example architectures for microservices, libraries, and FastAPI-style apps.

Quick Start

Instantiate a shared pool with a DatabaseConfig, create AsyncDatabaseManager instances per schema, and run migrations for each module. Then perform queries using the template syntax {{tables.*}}.

Frequently Asked Questions about using-pgdbm

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I manage multiple PostgreSQL schemas with a single connection pool?

Schema isolation with a shared pool centralizes connection management while keeping each service's data separate. Create one DatabaseConfig for the pool, then instantiate AsyncDatabaseManager per schema to operate independently while reusing connections.

How do I run database migrations independently for each module in a microservices app?

Per-module migrations let each service update its schema without blocking others. Run migrations for each AsyncDatabaseManager instance separately, all drawing from the same shared pool to minimize resource overhead.

What's the best way to write portable database queries across different deployment modes?

Template-driven queries using {{tables.*}} syntax decouple query logic from schema location. This portability means the same query works whether schemas are deployed locally, in containers, or across microservices.

Can I use a shared pool with schema isolation in multi-tenant or microservices architectures?

Yes. One shared pool with per-service schemas provides safe multi-tenancy and microservices isolation. Each module gets its own schema while the pool handles all connection coordination, reducing database load and operational complexity.

Do I need separate connection pools for each service if I'm using multiple schemas?

No. A single shared pool suffices for multiple schemas when using AsyncDatabaseManager. This design minimizes connection overhead while maintaining schema isolation and safe concurrent access across services.