postgres-pro
Senior-level PostgreSQL administration and performance tuning.
Install
mkdir -p .claude/skills/postgres-pro && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/9426" && unzip -o skill.zip -d .claude/skills/postgres-pro && rm skill.zipInstalls to .claude/skills/postgres-pro
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Use when optimizing PostgreSQL queries, configuring replication, or implementing advanced database features. Invoke for EXPLAIN analysis, JSONB operations, extension usage, VACUUM tuning, performance monitoring.Key capabilities
- →Analyze execution plans with EXPLAIN ANALYZE
- →Design B-tree, GIN, and GiST indexes
- →Configure streaming and logical replication
- →Tune autovacuum settings and monitor bloat
How it works
It systematically executes EXPLAIN statements to find bottlenecks and applies diagnostic monitoring of internal system views.
Inputs & outputs
When to use postgres-pro
- →Analyze slow queries with EXPLAIN
- →Configure streaming replication
- →Tune VACUUM and autovacuum settings
About this skill
PostgreSQL Pro
Senior PostgreSQL expert with deep expertise in database administration, performance optimization, and advanced PostgreSQL features.
When to Use This Skill
- Analyzing and optimizing slow queries with EXPLAIN
- Implementing JSONB storage and indexing strategies
- Setting up streaming or logical replication
- Configuring and using PostgreSQL extensions
- Tuning VACUUM, ANALYZE, and autovacuum
- Monitoring database health with pg_stat views
- Designing indexes for optimal performance
Core Workflow
- Analyze performance — Run
EXPLAIN (ANALYZE, BUFFERS)to identify bottlenecks - Design indexes — Choose B-tree, GIN, GiST, or BRIN based on workload; verify with
EXPLAINbefore deploying - Optimize queries — Rewrite inefficient queries, run
ANALYZEto refresh statistics - Setup replication — Streaming or logical based on requirements; monitor lag continuously
- Monitor and maintain — Track VACUUM, bloat, and autovacuum via
pg_statviews; verify improvements after each change
End-to-End Example: Slow Query → Fix → Verification
-- Step 1: Identify slow queries
SELECT query, mean_exec_time, calls
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;
-- Step 2: Analyze a specific slow query
EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
SELECT * FROM orders WHERE customer_id = 42 AND status = 'pending';
-- Look for: Seq Scan (bad on large tables), high Buffers hit, nested loops on large sets
-- Step 3: Create a targeted index
CREATE INDEX CONCURRENTLY idx_orders_customer_status
ON orders (customer_id, status)
WHERE status = 'pending'; -- partial index reduces size
-- Step 4: Verify the index is used
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders WHERE customer_id = 42 AND status = 'pending';
-- Confirm: Index Scan on idx_orders_customer_status, lower actual time
-- Step 5: Update statistics if needed after bulk changes
ANALYZE orders;
Reference Guide
Load detailed guidance based on context:
| Topic | Reference | Load When |
|---|---|---|
| Performance | references/performance.md | EXPLAIN ANALYZE, indexes, statistics, query tuning |
| JSONB | references/jsonb.md | JSONB operators, indexing, GIN indexes, containment |
| Extensions | references/extensions.md | PostGIS, pg_trgm, pgvector, uuid-ossp, pg_stat_statements |
| Replication | references/replication.md | Streaming replication, logical replication, failover |
| Maintenance | references/maintenance.md | VACUUM, ANALYZE, pg_stat views, monitoring, bloat |
Common Patterns
JSONB — GIN Index and Query
-- Create GIN index for containment queries
CREATE INDEX idx_events_payload ON events USING GIN (payload);
-- Efficient JSONB containment query (uses GIN index)
SELECT * FROM events WHERE payload @> '{"type": "login", "success": true}';
-- Extract nested value
SELECT payload->>'user_id', payload->'meta'->>'ip'
FROM events
WHERE payload @> '{"type": "login"}';
VACUUM and Bloat Monitoring
-- Check tables with high dead tuple counts
SELECT relname, n_dead_tup, n_live_tup,
round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_pct,
last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;
-- Manually vacuum a high-churn table and verify
VACUUM (ANALYZE, VERBOSE) orders;
Replication Lag Monitoring
-- On primary: check standby lag
SELECT client_addr, state, sent_lsn, write_lsn, flush_lsn, replay_lsn,
(sent_lsn - replay_lsn) AS replication_lag_bytes
FROM pg_stat_replication;
Constraints
MUST DO
- Use
EXPLAIN (ANALYZE, BUFFERS)for query optimization - Verify indexes are actually used with
EXPLAINbefore and after creation - Use
CREATE INDEX CONCURRENTLYto avoid table locks in production - Run
ANALYZEafter bulk data changes to refresh statistics - Monitor autovacuum; tune
autovacuum_vacuum_scale_factorfor high-churn tables - Use connection pooling (pgBouncer, pgPool)
- Monitor replication lag via
pg_stat_replication - Use prepared statements to prevent SQL injection
- Use
uuidtype for UUIDs, nottext
MUST NOT DO
- Disable autovacuum globally
- Create indexes without first analyzing query patterns
- Use
SELECT *in production queries - Ignore replication lag alerts
- Skip VACUUM on high-churn tables
- Store large BLOBs in the database (use object storage)
- Deploy index changes without verifying the planner uses them
Output Templates
When implementing PostgreSQL solutions, provide:
- Query with
EXPLAIN (ANALYZE, BUFFERS)output and interpretation - Index definitions with rationale and pre/post verification
- Configuration changes with before/after values
- Monitoring queries for ongoing health checks
- Brief explanation of performance impact
Knowledge Reference
PostgreSQL 12-16, EXPLAIN ANALYZE, B-tree/GIN/GiST/BRIN indexes, JSONB operators, streaming replication, logical replication, VACUUM/ANALYZE, pg_stat views, PostGIS, pgvector, pg_trgm, WAL archiving, PITR
When not to use it
- →For trivial queries that do not touch indexes
- →During peak production traffic without monitoring
Prerequisites
Limitations
- →Requires specific database privileges for deep inspection
- →Indexes consume storage and impact write speed
How it compares
It provides performance-specific diagnostic data rather than generic syntax correction.
Compared to similar skills
postgres-pro side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| postgres-pro (this skill) | 0 | 3mo | No flags | Advanced |
| sql-optimization-patterns | 64 | 2mo | No flags | Advanced |
| supabase-postgres-best-practices | 4 | 6mo | No flags | Intermediate |
| supabase-performance-tuning | 4 | 27d | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by Jeffallan
View all by Jeffallan →You might also like
sql-optimization-patterns
wshobson
Master SQL query optimization, indexing strategies, and EXPLAIN analysis to dramatically improve database performance and eliminate slow queries. Use when debugging slow queries, designing database schemas, or optimizing application performance.
supabase-postgres-best-practices
davila7
Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.
supabase-performance-tuning
jeremylongshore
Optimize Supabase API performance with caching, batching, and connection pooling. Use when experiencing slow API responses, implementing caching strategies, or optimizing request throughput for Supabase integrations. Trigger with phrases like "supabase performance", "optimize supabase", "supabase latency", "supabase caching", "supabase slow", "supabase batch".
analyzing-query-performance
jeremylongshore
Execute use when you need to work with query optimization. This skill provides query performance analysis with comprehensive guidance and automation. Trigger with phrases like "optimize queries", "analyze performance", or "improve query speed".
find-hypertable-candidates
timescale
Use this skill to analyze an existing PostgreSQL database and identify which tables should be converted to Timescale/TimescaleDB hypertables. **Trigger when user asks to:** - Analyze database tables for hypertable conversion potential - Identify time-series or event tables in an existing schema - Evaluate if a table would benefit from Timescale/TimescaleDB - Audit PostgreSQL tables for migration to Timescale/TimescaleDB/TigerData - Score or rank tables for hypertable candidacy **Keywords:** hypertable candidate, table analysis, migration assessment, Timescale, TimescaleDB, time-series detection, insert-heavy tables, event logs, audit tables Provides SQL queries to analyze table statistics, index patterns, and query patterns. Includes scoring criteria (8+ points = good candidate) and pattern recognition for IoT, events, transactions, and sequential data.
databases
mrgoonie
Work with MongoDB (document database, BSON documents, aggregation pipelines, Atlas cloud) and PostgreSQL (relational database, SQL queries, psql CLI, pgAdmin). Use when designing database schemas, writing queries and aggregations, optimizing indexes for performance, performing database migrations, configuring replication and sharding, implementing backup and restore strategies, managing database users and permissions, analyzing query performance, or administering production databases.