Managing postgres connections
Skill pumarogie/claude-postgres-skills/skills/managing-postgres-connections
Production Postgres survival skills for Claude Code — schema design, safe migrations, query performance, connection pooling, autovacuum/bloat, and queue/partitioning patterns.
npx -y skills add pumarogie/claude-postgres-skills --skill managing-postgres-connectionsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 15 days oldThe repository was created 15 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when configuring a Postgres connection pool, hitting max connection limits, seeing connection churn, or debugging connection-storm errors.
SKILL.md
2.0 KB, 405 tokens by cl100k_base, as published. Nobody here has run it
Managing Postgres Connections
Overview
Postgres connections are expensive — each costs CPU and memory. They should be long-lived and pooled. High connection churn wastes resources, and connection storms trigger internal Postgres locks that produce nasty, hard-to-reproduce edge cases.
When to Use
- Setting up how your app connects to Postgres.
- Hitting
too many connections/remaining connection slots are reserved. - Seeing latency spikes or lock contention under load that correlates with new connections.
- Running many app instances against one database.
Quick Reference
| Option | When | Notes |
|---|---|---|
| External pooler (pgbouncer) | Preferred | Sits in front of Postgres; one pool for all app instances |
| In-memory pooler (e.g. pgxpool for Go) | Fallback | Per-process; use when you can't run an external pooler |
| Open/close per request | Never | Churn burns CPU/memory and invites connection storms |
Rules
- Keep connections long-lived — acquire from a pool, return to the pool, don't reconnect per query.
- Prefer an external pooler (pgbouncer) so all instances share one bounded set of server connections.
- If you can't guarantee an external pooler (e.g. shipping software that runs against arbitrary
customer databases), use an in-memory pooler like
pgxpoolas a fallback. - Bound the pool size — more connections is not more throughput; past a point it's pure contention.
Common Mistakes
- Opening a fresh connection per request or per query — the storm pattern.
- No pooler at all, with many app instances each opening connections directly — you exhaust
max_connectionsand hit internal lock edge cases. - Setting the pool max very high "to be safe" — large connection counts increase lock contention inside Postgres rather than helping.
What ships with it: 1 file
3.4 KB alongside SKILL.md