Fähigkeiten supabase-postgres-best-practices
🐘

supabase-postgres-best-practices

Sicher ⚡ Enthält Skripte⚙️ Externe Befehle🌐 Netzwerkzugriff

Optimieren Sie die Postgres-Leistung mit Experten-Best-Practices

Auch verfügbar von: supabase

Langsame Abfragen und schlechtes Schema-Design plagen Postgres-Anwendungen. Dieser Skill bietet 26 priorisierte Regeln von Supabase-Experten zur Erzielung von 10-1000x Leistungsverbesserungen.

Unterstützt: Claude Codex Code(CC)
📊 70 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "supabase-postgres-best-practices". Überprüfen Sie meine Postgres-Abfrage und schlagen Sie Optimierungen basierend auf Best-Practices vor: SELECT * FROM events WHERE user_id = 123 ORDER BY created_at DESC LIMIT 20

Erwartetes Ergebnis:

Basierend auf query-missing-indexes.md Regeln benötigt Ihre Abfrage einen Index auf den Filter- und Sortierspalten:

1. Composite-Index hinzufügen:
```sql
CREATE INDEX events_user_id_created_at_idx
ON events (user_id, created_at DESC);
```

2. Erwartete Verbesserung: Index-Scan reduziert Kosten von 25.000 auf 8,44 (100-1000x schneller auf großen Tabellen).

3. Für LIMIT-Abfragen sollten Sie Covering-Indizes in Betracht ziehen, um Tabellen-Lookups zu vermeiden, wenn Sie nur bestimmte Spalten benötigen.

Verwendung von "supabase-postgres-best-practices". Folgt dieses Batch-Insert-Muster den Best-Practices? for (let i = 0; i < 1000; i++) { await db.query('INSERT INTO logs (message) VALUES ($1)', [logs[i]]); }

Erwartetes Ergebnis:

Nein, dies verletzt die Regeln aus data-batch-inserts.md. Sie haben:

- 1000 einzelne Round-Trips
- 1000 separate Transaktionen
- Geschätzt 10-50x langsamer als notwendig

Korrekter Ansatz (aus den Regeln):
```sql
INSERT INTO logs (message) VALUES
($1), ($2), ($3), ... bis zu ~1000 Zeilen;
```

Oder verwenden Sie COPY für Massenimporte (schnellste Methode). Siehe data-batch-inserts.md für Beispiele.

Verwendung von "supabase-postgres-best-practices". Sollte ich einen Index auf dieser Fremdschlüsselspalte hinzufügen, die occasionally abgefragt wird?

Erwartetes Ergebnis:

Ja, absolut. Aus schema-foreign-key-indexes.md:

**Auswirkung: KRITISCH (5-20x Verbesserung)**

Fremdschlüsselspalten sollten fast immer indiziert werden, weil:
1. JOINs auf Fremdschlüsseln ohne Indizes sequenzielle Scans verursachen
2. DELETEs auf übergeordneten Tabellen erfordern das Scannen von untergeordneten Tabellen
3. Kaskadenoperationen werden exponentiell langsamer auf großen Tabellen

Die Regel merkt an: Sogar gelegentliche Abfragen profitieren von der Indizierung von Fremdschlüsseln aufgrund exponentieller Scan-Kosten.

Sicherheitsaudit

Sicher
v1 • 2/25/2026

All 710 static findings are false positives. This is a documentation-only skill containing Postgres best practices in Markdown format. The flagged patterns (backticks, MD5 references, URLs, system queries) are all legitimate SQL examples, documentation links, and monitoring queries. No executable code, no data exfiltration, no malicious intent detected.

37
Gescannte Dateien
3,485
Analysierte Zeilen
8
befunde
1
Gesamtzahl Audits
Probleme mit mittlerem Risiko (1)
False Positive - SQL Code Blocks Flagged as External Commands
Static scanner detected 344 instances of 'Ruby/shell backtick execution' across Markdown files. Investigation confirms these are Markdown code blocks containing SQL examples (e.g., ```sql ... ```) and inline backticks for emphasis. No actual shell execution exists. Confidence: 0.98 - Direct evidence that backticks are Markdown syntax, not executable code.
Probleme mit niedrigem Risiko (4)
False Positive - MD5 References Not Cryptographic Weakness
Static scanner flagged 46 instances of 'Weak cryptographic algorithm (MD5)'. Investigation confirms these are: (1) MD5 checksums in documentation URLs (Supabase/PostgreSQL docs), (2) File integrity hashes in metadata.json, not actual cryptographic implementations. No security risk. Confidence: 0.95 - Clear evidence these are documentation references, not crypto code.
False Positive - Hardcoded URLs Are Legitimate Documentation Links
Static scanner detected 72 'Hardcoded URL' instances. Investigation confirms all are legitimate documentation references to supabase.com/docs and postgresql.org/docs. No external data exfiltration, no malicious endpoints. Confidence: 0.99 - All URLs point to official Supabase/PostgreSQL documentation.
False Positive - System Queries Are Legitimate Monitoring
Static scanner flagged 158 'System reconnaissance' patterns. Investigation confirms these are standard PostgreSQL monitoring queries (pg_stat_activity, pg_class, pg_indexes) used for performance diagnostics. No reconnaissance activity. Confidence: 0.97 - Standard Postgres system catalog queries for DBA monitoring.
False Positive - SQL WITH Clauses Not JavaScript with Statements
Static scanner detected 4 'with statement (deprecated)' patterns. Investigation confirms these are SQL Common Table Expressions (CTEs) using 'WITH' clause, not deprecated JavaScript 'with' statements. No scope confusion risk. Confidence: 0.99 - Clearly SQL syntax in Postgres documentation.
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
31
Community
92
Sicherheit
91
Spezifikationskonformität

Was du bauen kannst

Fehlerbehebung bei Abfrage-Leistung

Entwickler mit langsamen API-Endpunkten verwendet Abfrageoptimierungsregeln, um Indizes hinzuzufügen und Abfragen umzuschreiben für 100-1000x Verbesserung.

Überprüfung des Datenbank-Schema-Designs

Datenbank-Architekt überprüft Schema-Designregeln vor dem Start einer Multi-Tenant-SaaS-Anwendung, um kostspielige Refactorings zu vermeiden.

Postgres-Migrationsplanung

DevOps-Ingenieur plant Migration von Single-Tenant zu Multi-Tenant-Architektur unter Verwendung von RLS- und Connection-Pooling-Richtlinien.

Probiere diese Prompts

Grundlegende Abfrageoptimierung
Ich habe eine langsame Postgres-Abfrage. Helfen Sie mir, sie mit Best-Practices aus dem supabase-postgres-best-practices Skill zu optimieren.

Meine Abfrage:
```sql
SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending'
```

Tabelle hat 10 Millionen Zeilen. Abfrage dauert 5 Sekunden.
Überprüfung der Index-Strategie
Überprüfen Sie meine Indizierungsstrategie für dieses Schema mit dem supabase-postgres-best-practices Skill. Konzentrieren Sie sich auf Composite-Indizes, Partial-Indizes und Fremdschlüssel-Indizierung.

Schema:
- users-Tabelle (1M Zeilen)
- orders-Tabelle (5M Zeilen, Fremdschlüssel zu users)
- Abfragemuster: Häufig filtern nach user_id + created_at + status
RLS-Policy-Optimierung
Ich implementiere Row-Level Security für Multi-Tenant-Daten mit supabase-postgres-best-practices. Helfen Sie mir, RLS-Policies zu optimieren.

Aktuelle Policy:
```sql
CREATE POLICY user_isolation ON documents
  USING (auth.uid() = user_id)
  WITH CHECK (auth.uid() = user_id);
```

Abfrageleistung verschlechterte sich 5x nach Aktivierung von RLS.
Connection-Pooling-Konfiguration
Helfen Sie mir, Connection Pooling für eine Node.js-Anwendung mit Supabase zu konfigurieren mit supabase-postgres-best-practices.

Anforderungen:
- 1000 gleichzeitige Benutzer
- Durchschnittliche Abfragezeit: 50ms
- Verwendung von PgBouncer
- Verbindungsauslöschungsfehler auftreten

Geben Sie spezifische Konfigurationswerte an und erklären Sie Trade-offs.

Bewährte Verfahren

  • Erstellen Sie immer Indizes auf WHERE-, JOIN- und ORDER BY-Spalten vor der Bereitstellung in der Produktion
  • Verwenden Sie cursor-basierte Paginierung mit indizierten Spalten statt OFFSET für große Ergebnismengen
  • Halten Sie Transaktionen kurz (unter 1 Sekunde) und vermeiden Sie Benutzerinteraktionen mitten in der Transaktion, um Sperrenkonflikte zu verhindern

Vermeiden

  • Verwendung von SELECT * auf großen Tabellen, wenn nur bestimmte Spalten benötigt werden (verursacht unnötige I/O und verhindert Covering-Index-Optimierung)
  • Ausführen einzelner INSERT-Anweisungen innerhalb von Schleifen statt Batching von Zeilen oder Verwendung von COPY
  • Erstellen von Indizes ohne Analyse von Abfragemustern mit EXPLAIN ANALYZE (manche Indizes können die Schreibleistung beeinträchtigen, ohne das Lesen zu verbessern)

Häufig gestellte Fragen

Wie weiß ich, welche Spalten Indizes benötigen?
Verwenden Sie die missing indexes query aus query-missing-indexes.md, um häufig zugegriffene Spalten ohne Indizes zu identifizieren. Führen Sie EXPLAIN ANALYZE für langsamen Abfragen aus, um sequenzielle Scans zu erkennen. Priorisieren Sie WHERE- und JOIN-Spalten, die in anwendungskritischen Abfragen verwendet werden.
Sollte ich jeden Fremdschlüssel indizieren?
Fast immer ja. Laut schema-foreign-key-indexes.md bieten Fremdschlüssel-Indizes 5-20x Verbesserung für JOINs und verhindern Kaskaden-DELETE-Leistungsprobleme. Nur überspringen, wenn die Spalte nie abgefragt oder gejoined wird.
Warum ist cursor-basierte Paginierung besser als OFFSET?
OFFSET erfordert das Scannen und Verwerfen aller vorherigen Zeilen und wird mit tieferer Paginierung langsamer. Cursor-basierte Paginierung (unter Verwendung von indizierten WHERE-Klauseln) hat O(1)-Leistung unabhängig von der Seitentiefe. Siehe data-pagination.md für Implementierungsbeispiele.
Wie viele Connection Pooler benötige ich für Supabase?
Aus conn-pooling.md: Verwenden Sie PgBouncer im Transaktionsmodus. Pool-Größe sollte (Anzahl der Anwendungsserver × Verbindungen pro Server) sein. Für 1000 gleichzeitige Benutzer mit 50ms-Abfragen beginnen Sie mit einer Pool-Größe von 20-50 und überwachen auf Auslöschungsfehler.
Beeinflusst Row-Level Security (RLS) die Leistung?
Ja, RLS kann 2-5x Overhead hinzufügen, wenn Policies suboptimal sind. security-rls-performance.md erklärt, Indizes auf Policy-Spalten zu verwenden, Subqueries in Policies zu vermeiden und security_invoker-Views zu verwenden. Richtig abgestimmte RLS-Policies erhalten Sicherheit mit minimalem Leistungsaufwand.
Kann ich diese Regeln mit rohem PostgreSQL oder nur mit Supabase verwenden?
Alle Kernregeln gelten für rohes PostgreSQL. Supabase-spezifische Hinweise (Connection-Pooling-Standardeinstellungen, verwaltetes RLS) sind deutlich gekennzeichnet. Die Indizierungs-, Abfrageoptimierungs- und Schema-Design-Regeln funktionieren identisch in jeder Postgres 14+-Bereitstellung.