supabase-postgres-best-practices
전문가 모범 사례로 Postgres 성능 최적화하기
또한 다음에서 사용할 수 있습니다: supabase
느린 쿼리와 부적절한 스키마 설계는 Postgres 애플리케이션의 고질적인 문제입니다. 이 스킬은 10~1000 배 성능 향상을 달성하기 위한 Supabase 전문가의 26 가지 우선순위 규칙을 제공합니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"supabase-postgres-best-practices" 사용 중입니다. Review my Postgres query and suggest optimizations based on best practices: SELECT * FROM events WHERE user_id = 123 ORDER BY created_at DESC LIMIT 20
예상 결과:
query-missing-indexes.md 규칙에 따르면, 쿼리에 필터 및 정렬 칼럼에 대한 인덱스가 필요합니다:
1. 복합 인덱스 추가:
```sql
CREATE INDEX events_user_id_created_at_idx
ON events (user_id, created_at DESC);
```
2. 예상 개선: 인덱스 스캔으로 비용이 25,000 에서 8.44 로 감소합니다 (대규모 테이블에서 100~1000 배 빠름).
3. LIMIT 쿼리의 경우, 특정 칼럼만 필요한 경우 커버링 인덱스를 사용하여 테이블 조회를 피하는 것을 고려하세요.
"supabase-postgres-best-practices" 사용 중입니다. Is this batch insert pattern following best practices? for (let i = 0; i < 1000; i++) { await db.query('INSERT INTO logs (message) VALUES ($1)', [logs[i]]); }
예상 결과:
아니요, 이는 data-batch-inserts.md 규칙을 위반합니다:
- 1000 개의 개별 라운드트립
- 1000 개의 별도 트랜잭션
- 필요보다 10~50 배 느린 것으로 추정
올바른 접근 방식 (규칙 참조):
```sql
INSERT INTO logs (message) VALUES
($1), ($2), ($3), ... up to ~1000 rows;
```
또는 대량 가져오기의 경우 COPY 를 사용하세요 (가장 빠른 방법). 예시는 data-batch-inserts.md 를 참조하세요.
"supabase-postgres-best-practices" 사용 중입니다. Should I add an index on this foreign key column that gets queried occasionally?
예상 결과:
네, 확실합니다. schema-foreign-key-indexes.md 에 따르면:
**영향력: 중요 (5~20 배 향상)**
외래 키 칼럼은 거의 항상 인덱스가 있어야 합니다. 이유는:
1. 외래 키에 대한 JOIN 은 인덱스 없이 순차 스캔을 발생시킵니다
2. 부모 테이블의 DELETE 는 자식 테이블 스캔이 필요합니다
3. 캐스케이드 연산은 대규모 테이블에서 기하급수적으로 느려집니다
규칙 노트: 때때로만 쿼리되는 경우에도 인덱스 비용이 기하급수적으로 증가하므로 외래 키 인덱싱의 이점을 얻을 수 있습니다.
보안 감사
안전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.
중간 위험 문제 (1)
낮은 위험 문제 (4)
위험 요인
⚡ 스크립트 포함 (1)
품질 점수
만들 수 있는 것
쿼리 성능 문제 해결
느린 API 엔드포인트를 경험하는 개발자가 쿼리 최적화 규칙을 사용하여 인덱스를 추가하고 쿼리를 재작성하여 100~1000 배 개선을 달성합니다.
데이터베이스 스키마 설계 검토
데이터베이스 설계자가 비용이 많이 드는 리팩토링을 피하기 위해 멀티테넌트 SaaS 애플리케이션 출시 전에 스키마 설계 규칙을 검토합니다.
Postgres 마이그레이션 계획
DevOps 엔지니어가 RLS 및 커넥션 풀링 가이드라인을 사용하여 싱글테넌트에서 멀티테넌트 아키텍처로의 마이그레이션을 계획합니다.
이 프롬프트를 사용해 보세요
I have a slow Postgres query. Help me optimize it using best practices from the supabase-postgres-best-practices skill. My query: ```sql SELECT * FROM orders WHERE customer_id = 123 AND status = 'pending' ``` Table has 10 million rows. Query takes 5 seconds.
Review my indexing strategy for this schema using the supabase-postgres-best-practices skill. Focus on composite indexes, partial indexes, and foreign key indexing. Schema: - users table (1M rows) - orders table (5M rows, foreign key to users) - Query pattern:经常 filter by user_id + created_at + status
I'm implementing Row-Level Security for multi-tenant data using supabase-postgres-best-practices. Help me optimize RLS policies. Current policy: ```sql CREATE POLICY user_isolation ON documents USING (auth.uid() = user_id) WITH CHECK (auth.uid() = user_id); ``` Query performance degraded 5x after enabling RLS.
Help me configure connection pooling for a Node.js application with Supabase using supabase-postgres-best-practices. Requirements: - 1000 concurrent users - Average query time: 50ms - Using PgBouncer - Experiencing connection exhaustion errors Provide specific configuration values and explain trade-offs.
모범 사례
- 프로덕션 배포 전에 WHERE, JOIN, ORDER BY 칼럼에 항상 인덱스를 생성하세요
- 대규모 결과 세트의 경우 OFFSET 대신 인덱스된 칼럼으로 커서 기반 페이지네이션을 사용하세요
- 락 경합을 방지하기 위해 트랜잭션을 짧게 (1 초 미만) 유지하고 트랜잭션 중간에 사용자 상호작용을 피하세요
피하기
- 특정 칼럼만 필요한 경우 대량의 테이블에서 SELECT * 사용 (불필요한 I/O 를 발생시키고 커버링 인덱스 최적화를 방지함)
- 행 배칭이나 COPY 사용 대신 루프 내에서 개별 INSERT 문 실행
- EXPLAIN ANALYZE 로 쿼리 패턴을 분석하지 않고 인덱스 생성 (일부 인덱스는 읽기에 도움이 되지 않고 쓰기 성능을 저하시킬 수 있음)