{ }
Resource profile / PostgreSQL Performance & Schema Review
About this skill

Workflow & requirements

Supabase Postgres Best Practices

Comprehensive performance optimization guide for Postgres, maintained by Supabase. Contains rules across 8 categories, prioritized by impact to guide automated query optimization and schema design.

When to Apply

Reference these guidelines when: - Writing SQL queries or designing schemas - Implementing indexes or query optimization - Reviewing database performance issues - Configuring connection pooling or scaling - Optimizing for Postgres-specific features - Working with Row-Level Security (RLS)

Rule Categories by Priority

Priority Category Impact Prefix
1 Query Performance CRITICAL query-
2 Connection Management CRITICAL conn-
3 Security & RLS CRITICAL security-
4 Schema Design HIGH schema-
5 Concurrency & Locking MEDIUM-HIGH lock-
6 Data Access Patterns MEDIUM data-
7 Monitoring & Diagnostics LOW-MEDIUM monitor-
8 Advanced Features LOW advanced-

How to Use

Read individual rule files for detailed explanations and SQL examples:

references/query-missing-indexes.md
references/query-partial-indexes.md
references/_sections.md

Each rule file contains: - Brief explanation of why it matters - Incorrect SQL example with explanation - Correct SQL example with explanation - Optional EXPLAIN output or metrics - Additional context and references - Supabase-specific notes (when applicable)

References

  • https://www.postgresql.org/docs/current/
  • https://supabase.com/docs
  • https://wiki.postgresql.org/wiki/Performance_Optimization
  • https://supabase.com/docs/guides/database/overview
  • https://supabase.com/docs/guides/auth/row-level-security
PACKAGE TRANSPARENCY

Inspect before installing

Source: Supabase · MIT · SHA-256 shown alongside the download.

40 files38701 ZIP bytes0 script/code files

License file included. A license and checksum are not a security certification. Review package instructions and scripts before running them.

View files and uncompressed sizes
Machine-readable installation guide →
CATALOG REVIEW NOTES

Know what you need before installing

Source and packaging checks recorded on 2026-10-03. These notes are not safety certification or measured task performance.

Requirements

A PostgreSQL project and access to schema/query context; read-only EXPLAIN where appropriate. Some rules require extensions or Supabase-specific configuration.

Costs, access & practical limits

Use representative data and measure actual plans. EXPLAIN ANALYZE executes queries; mutations, migrations, restores, and hosted services need separate approval. Example speedups are not catalog benchmarks.

View the recorded checks
  • Pinned upstream source and Git blob hashes verified
  • Applicable original license and notices preserved
  • Archive paths and metadata validated
  • Local Markdown and named reference files checked

Upstream commit: c9be0e931b7930f7d02126d04774d904c381e7d7

Runtime status: not tested by this catalog. Configure your client and test the skill in your own environment.

SCENARIOS

Inputs, criteria and recorded outcomes

Records are supplied by the site administrator and bound to a specific package. They are not third-party safety certification. This page does not execute skills.

Missing-index SQL recipe (isolated synthetic workload)

Reported passed · vc9be0e931b79

View input and acceptance criteria

Input

Create an isolated PostgreSQL 17 database with 200,000 synthetic orders and 10,000 customer IDs. Filter customer_id = 123. Compare EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) before and after CREATE INDEX orders_customer_id_idx ON orders (customer_id). Take one warmup and five measured runs per condition. Do not connect to a production database.

Acceptance criteria

Both result sets contain the same 20 rows. The baseline uses Seq Scan; the indexed plan uses orders_customer_id_idx. Record actual timings and limitations; no speedup threshold is required. Scope: one SQL recipe, not an agent benchmark.

Recorded outcome

Scope: direct SQL recipe validation, not an AI-agent end-to-end evaluation.
200,000 synthetic orders; customer_id = 123 matches 20 rows.
Before: Seq Scan. After: Bitmap Heap Scan with orders_customer_id_idx.
Result rows and SHA-256 match before and after.
Five warmed measurements: median 12.676 ms before; 0.152 ms after.
Timing is specific to this workload, cache, and hardware. Runs are sequential, not randomized.
No production queries, third-party scripts, or paid AI calls were used.
Only the missing-index recipe was checked; no full-skill effectiveness or safety certification is implied.
Result SHA-256: f72cd8761469a9f1c53d4d7fd478d05857f685a5395e7300ae98ad696cdac8fb
Probe script SHA-256: 0a429cdfed4779f645767cd945d08cda58df801be271037ae362cb2f191337b7

Environment

PostgreSQL 17.11 on x86_64-pc-linux-musl, compiled by gcc (Alpine 15.2.0) 15.2.0, 64-bit; Docker isolated database; 1 CPU and 512 MiB database limit; parallel query disabled.

Package SHA-256: 2e93a64c76cbde8d4dd1b7d8c6896f21492d0425b8ff25fcc69d97769b4f0e3d

Outcome recorded: 2026-10-02 17:17 UTC

Community reviews

★ New

Be the first to share your experience.

Sign in to leave a review →

More to explore

View all ↗