PostgreSQL Specialist
Use this skill to produce evidence-driven PostgreSQL guidance that is safe for production and efficient for the user's environment. Favor the smallest change with the highest likely impact.
Primary Use Cases
- Optimize slow PostgreSQL or Supabase queries
- Interpret
EXPLAIN or EXPLAIN ANALYZE
- Design or validate indexes
- Diagnose planner misestimates and stale statistics
- Implement or tune JSONB storage, operators, and indexing
- Configure or evaluate extensions such as
pg_stat_statements, pg_trgm, pgvector, and PostGIS
- Diagnose replication topology, lag, and WAL retention
- Tune VACUUM, ANALYZE, autovacuum, and bloat monitoring
First Classify the Request
Choose the primary lane, then load only the matching reference file(s):
- Performance / query tuning —
references/performance.md
- JSONB / document-style querying —
references/jsonb.md
- Extensions —
references/extensions.md
- Replication / HA —
references/replication.md
- Maintenance / autovacuum / bloat / monitoring —
references/maintenance.md
Load a second reference only when the issue clearly spans two lanes, such as JSONB plus performance or replication plus maintenance. Do not load every reference file by default.
Core Workflow
Confirm environment constraints
- PostgreSQL version
- Managed vs self-hosted
- Supabase or standard PostgreSQL
- Read/write profile, table size, query frequency, latency target
- What the user can actually change: SQL only, indexes/migrations, extensions, database settings, or infrastructure
Collect evidence before recommending changes
- Query text
- Schema and current indexes
- Relevant
EXPLAIN or EXPLAIN ANALYZE
- Cardinality and selectivity clues
pg_stat_statements, pg_stat_user_tables, replication, or autovacuum stats when relevant
Diagnose the bottleneck
Common causes include:
- Missing or poorly ordered index
- Query shape forcing expensive scans, joins, sorts, or aggregates
- Stale statistics or skewed data distribution
- JSONB operator and index mismatch
- Table or index bloat
- Autovacuum starvation or long transactions
- Replication slot lag or WAL retention growth
- Managed-service limits or unsupported config changes
Propose the smallest high-leverage fix
Prefer this order unless evidence points elsewhere:
- Query rewrite
- Better index or index removal
- Statistics refresh or planner-target adjustment
- Table-level autovacuum tuning
- Extension enablement or operator change
- Infrastructure or server-config changes only when truly needed
Define validation and rollback
- What should improve
- How to measure it
- How to undo the change if it regresses behavior
If critical evidence is missing, state what is missing, separate confirmed findings from hypotheses, and still offer the safest low-risk next step.
Safety and Accuracy Rules
- Use
EXPLAIN (ANALYZE, BUFFERS) for read queries when safe.
- For write queries in production, do not casually run
EXPLAIN ANALYZE; prefer plain EXPLAIN, or use an explicit transaction with rollback if the environment allows it.
- Do not prescribe indexes unless they map to actual predicates, joins, sort order, or operator usage.
- Do not disable autovacuum globally.
- Do not jump to
VACUUM FULL on active production tables without warning about locks and considering safer alternatives.
- Do not assume superuser access or direct config-file control on Supabase or other managed PostgreSQL providers.
- Do not recommend provider-unsupported extensions or settings without saying they must be verified first.
- Prefer exact column lists over
SELECT * in tuned production queries.
- Mention write amplification, storage cost, lock risk, and migration impact for every new index or config change.
- Never fabricate execution-plan details or monitoring output that were not provided.
Lane-Specific Guidance
Performance
Load references/performance.md.
Focus on:
- estimated vs actual row mismatch
- scan type, join type, sort, and aggregate hot spots
- buffer reads vs cache hits
- composite index order
- partial, expression, covering, GIN, GiST, or BRIN index fit
ANALYZE after bulk changes
JSONB
Load references/jsonb.md.
Focus on:
- operator choice such as
@>, ?, ->>, and path operators
- default GIN vs
jsonb_path_ops
- expression indexes or generated columns for hot scalar filters
- when JSONB should be normalized into first-class columns
Extensions
Load references/extensions.md.
Focus on:
- whether the extension is installable in the target environment
pg_stat_statements for evidence collection
pg_trgm, pgvector, uuid-ossp, and PostGIS fit and tradeoffs
- extension-specific index and operator patterns
Replication
Load references/replication.md.
Focus on:
- physical vs logical replication choice
- RPO/RTO and sync vs async tradeoffs
- lag measurement, slot retention, and WAL growth
- failover and client-routing implications
Maintenance
Load references/maintenance.md.
Focus on:
- dead tuples, bloat risk, and last vacuum/analyze times
- per-table autovacuum tuning for high-churn tables
- long-running transactions preventing cleanup
- monitoring queries that show whether the fix is working
Response Contract
When using this skill, provide:
- Diagnosis — likely root cause and why
- Evidence used — plan stats, pg_stat output, or the exact missing data needed
- Recommended change — SQL, index DDL, config change, or maintenance/replication action
- Tradeoffs — write overhead, lock risk, storage cost, and operational risk
- Validation — exact queries or metrics to rerun
- Rollback — how to undo the change when applicable
Default Output Shape
Use this format unless the user asked for something else:
## Findings
- ...
## Recommended SQL / config
```sql
...
Why this should help
Validation
...
Risks / rollback
## Knowledge Reference
PostgreSQL 12-16, EXPLAIN, 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
1---2name: db-postgres3description: Use when the task is specifically about PostgreSQL or Supabase behavior such as slow queries, EXPLAIN plans, index design, JSONB querying, pg_stat analysis, VACUUM/autovacuum, replication, extensions, pgvector, pg_trgm, or PostGIS. Invoke whenever the user needs Postgres-specific diagnosis or exact SQL/config guidance rather than generic database advice, including cases framed as query tuning, replication lag, database bloat, managed Postgres limits, or production-safe performance work. Load with read_file on .kilocode/skills/db-postgres/SKILL.md (ignore the absolute path in the location tag).4license: MIT5---67# PostgreSQL Specialist89Use this skill to produce evidence-driven PostgreSQL guidance that is safe for production and efficient for the user's environment. Favor the smallest change with the highest likely impact.1011## Primary Use Cases1213- Optimize slow PostgreSQL or Supabase queries14- Interpret `EXPLAIN` or `EXPLAIN ANALYZE`15- Design or validate indexes16- Diagnose planner misestimates and stale statistics17- Implement or tune JSONB storage, operators, and indexing18- Configure or evaluate extensions such as `pg_stat_statements`, `pg_trgm`, `pgvector`, and PostGIS19- Diagnose replication topology, lag, and WAL retention20- Tune VACUUM, ANALYZE, autovacuum, and bloat monitoring2122## First Classify the Request2324Choose the primary lane, then load only the matching reference file(s):2526- **Performance / query tuning** — `references/performance.md`27- **JSONB / document-style querying** — `references/jsonb.md`28- **Extensions** — `references/extensions.md`29- **Replication / HA** — `references/replication.md`30- **Maintenance / autovacuum / bloat / monitoring** — `references/maintenance.md`3132Load a second reference only when the issue clearly spans two lanes, such as JSONB plus performance or replication plus maintenance. Do not load every reference file by default.3334## Core Workflow35361. **Confirm environment constraints**37 - PostgreSQL version38 - Managed vs self-hosted39 - Supabase or standard PostgreSQL40 - Read/write profile, table size, query frequency, latency target41 - What the user can actually change: SQL only, indexes/migrations, extensions, database settings, or infrastructure42432. **Collect evidence before recommending changes**44 - Query text45 - Schema and current indexes46 - Relevant `EXPLAIN` or `EXPLAIN ANALYZE`47 - Cardinality and selectivity clues48 - `pg_stat_statements`, `pg_stat_user_tables`, replication, or autovacuum stats when relevant49503. **Diagnose the bottleneck**51 Common causes include:52 - Missing or poorly ordered index53 - Query shape forcing expensive scans, joins, sorts, or aggregates54 - Stale statistics or skewed data distribution55 - JSONB operator and index mismatch56 - Table or index bloat57 - Autovacuum starvation or long transactions58 - Replication slot lag or WAL retention growth59 - Managed-service limits or unsupported config changes60614. **Propose the smallest high-leverage fix**62 Prefer this order unless evidence points elsewhere:63 - Query rewrite64 - Better index or index removal65 - Statistics refresh or planner-target adjustment66 - Table-level autovacuum tuning67 - Extension enablement or operator change68 - Infrastructure or server-config changes only when truly needed69705. **Define validation and rollback**71 - What should improve72 - How to measure it73 - How to undo the change if it regresses behavior7475If critical evidence is missing, state what is missing, separate confirmed findings from hypotheses, and still offer the safest low-risk next step.7677## Safety and Accuracy Rules7879- Use `EXPLAIN (ANALYZE, BUFFERS)` for read queries when safe.80- For write queries in production, do not casually run `EXPLAIN ANALYZE`; prefer plain `EXPLAIN`, or use an explicit transaction with rollback if the environment allows it.81- Do not prescribe indexes unless they map to actual predicates, joins, sort order, or operator usage.82- Do not disable autovacuum globally.83- Do not jump to `VACUUM FULL` on active production tables without warning about locks and considering safer alternatives.84- Do not assume superuser access or direct config-file control on Supabase or other managed PostgreSQL providers.85- Do not recommend provider-unsupported extensions or settings without saying they must be verified first.86- Prefer exact column lists over `SELECT *` in tuned production queries.87- Mention write amplification, storage cost, lock risk, and migration impact for every new index or config change.88- Never fabricate execution-plan details or monitoring output that were not provided.8990## Lane-Specific Guidance9192### Performance9394Load `references/performance.md`.95Focus on:96- estimated vs actual row mismatch97- scan type, join type, sort, and aggregate hot spots98- buffer reads vs cache hits99- composite index order100- partial, expression, covering, GIN, GiST, or BRIN index fit101- `ANALYZE` after bulk changes102103### JSONB104105Load `references/jsonb.md`.106Focus on:107- operator choice such as `@>`, `?`, `->>`, and path operators108- default GIN vs `jsonb_path_ops`109- expression indexes or generated columns for hot scalar filters110- when JSONB should be normalized into first-class columns111112### Extensions113114Load `references/extensions.md`.115Focus on:116- whether the extension is installable in the target environment117- `pg_stat_statements` for evidence collection118- `pg_trgm`, `pgvector`, `uuid-ossp`, and PostGIS fit and tradeoffs119- extension-specific index and operator patterns120121### Replication122123Load `references/replication.md`.124Focus on:125- physical vs logical replication choice126- RPO/RTO and sync vs async tradeoffs127- lag measurement, slot retention, and WAL growth128- failover and client-routing implications129130### Maintenance131132Load `references/maintenance.md`.133Focus on:134- dead tuples, bloat risk, and last vacuum/analyze times135- per-table autovacuum tuning for high-churn tables136- long-running transactions preventing cleanup137- monitoring queries that show whether the fix is working138139## Response Contract140141When using this skill, provide:1421. **Diagnosis** — likely root cause and why1432. **Evidence used** — plan stats, pg_stat output, or the exact missing data needed1443. **Recommended change** — SQL, index DDL, config change, or maintenance/replication action1454. **Tradeoffs** — write overhead, lock risk, storage cost, and operational risk1465. **Validation** — exact queries or metrics to rerun1476. **Rollback** — how to undo the change when applicable148149## Default Output Shape150151Use this format unless the user asked for something else:152153```markdown154## Findings155- ...156157## Recommended SQL / config158```sql159...160```161162## Why this should help163- ...164165## Validation166```sql167...168```169170## Risks / rollback171- ...172```173174## Knowledge Reference175176PostgreSQL 12-16, EXPLAIN, 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