PostgreSQL Operations

Use this skill to operate PostgreSQL safely as the database engine it is: review configuration against workload, find index and query-plan problems, manage vacuum and bloat, set up and verify WAL archiving and point-in-time recovery, run replication with a defensible failover plan, handle extensions, plan major-version upgrades, and diagnose incidents with evidence. This is a tool skill for one named tool (PostgreSQL). Database methodology — backup strategy across engines, migration patterns, SQL analytical patterns — lives in data-engineering; application-level data access patterns belong to backend-engineering; schema and data modeling belong to data-architect and data-engineering. Supabase platform administration is supabase.

Operating contract

1. Read-only discovery before any mutation. Inspect configuration, catalog statistics, and logs first. The bundled pgdiag script collects read-only evidence and opens every session with default_transaction_read_only=on.
2. Confirm the target, scope, and rollback path before acting. Read-only discovery may proceed without confirmation. Mutations — a pg_ctl stop, a promotion, an extension install, a pg_upgrade run — require an explicit human directive naming the instance.
3. A backup is not recovery evidence. Verify restore on a scratch instance on a schedule; never claim recoverability from a backup log alone.
4. Keep evidence bounded. Summarize catalog queries and log excerpts; never dump full logs, postgresql.conf, or connection strings with passwords into chat.
5. Verify at the delivery boundary. A SELECT 1 answer proves connectivity, not health; a replayed pg_basebackup proves recoverability, not that today's WAL is being archived.

The pgdiag script

scripts/pgdiag is an agent-first, read-only diagnostic collector. It shells out to psql, opens every session with default_transaction_read_only=on, and emits bounded JSON. --help works with no server and no psql installed.