postgres-best-practices
PostgreSQL 쿼리 및 스키마 최적화
느린 데이터베이스 쿼리와 성능 저하로 어려움을 겪고 계신가요? 이 스킬은 Supabase에서 검증된 PostgreSQL 최적화 규칙을 구체적인 SQL 예시와 측정 가능한 성능 개선과 함께 제공합니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"postgres-best-practices" 사용 중입니다. This query takes 5 seconds on 100k rows: SELECT * FROM orders WHERE customer_id = 42 AND status = 'pending'
예상 결과:
Create a composite index: CREATE INDEX idx_orders_customer_status ON orders (customer_id, status). This changes the execution plan from sequential scan to index scan, reducing query time to under 10ms. The column order matters: place the equality filter (customer_id) before the status filter for optimal index usage.
"postgres-best-practices" 사용 중입니다. How do I prevent N+1 queries when fetching users with their profile data?
예상 결과:
Replace individual queries with a JOIN: SELECT u.*, p.bio, p.avatar_url FROM users u LEFT JOIN user_profiles p ON p.user_id = u.id. Add an index on user_profiles(user_id) for fast lookups. This reduces 101 queries (1 for users + 100 for profiles) to a single query.
보안 감사
안전This skill contains educational documentation for PostgreSQL best practices from Supabase. All 711 static analysis findings are false positives: the 'external_commands' detections are SQL code blocks in markdown documentation (not shell commands), 'network' URLs are reference links to postgresql.org and supabase.com, 'scripts' findings are SQL WITH clauses (CTEs), and 'crypto' warnings are text pattern matches in documentation. No executable code or security risks present.
품질 점수
만들 수 있는 것
느린 쿼리를 최적화하는 백엔드 개발자
누락된 인덱스 식별, N+1 패턴 수정, 쿼리 최적화 기법을 적용하여 응답 시간을 초 단위에서 밀리초 단위로 단축합니다.
새 스키마를 설계하는 데이터베이스 아키텍트
초기 스키마 설계 시 데이터 유형, 제약 조건, 외래 키 및 인덱싱 전략에 대한 모범 사례를 적용합니다.
프로덕션 데이터베이스를 튜닝하는 DevOps 엔지니어
연결 제한, vacuum 설정 및 모니터링을 구성하여 부하状态下에서 데이터베이스 상태를 유지합니다.
이 프롬프트를 사용해 보세요
Review this PostgreSQL query for performance issues and suggest improvements: [paste query]
Analyze this table schema and query workload. What indexes should I create for optimal performance? Schema: [paste schema], Queries: [paste queries]
I'm fetching users and their orders with separate queries. Show me how to rewrite this as a single efficient JOIN with proper indexing.
Create a Row-Level Security policy for a multi-tenant SaaS where users can only access data belonging to their organization. Table structure: [paste schema]
모범 사례
- 항상 WHERE, JOIN 및 ORDER BY 열에 인덱스 추가
- 배포 전 EXPLAIN ANALYZE로 쿼리 실행 계획 확인
- 데이터베이스 고갈을 방지하려면 연결 풀링 구현
피하기
- 대규모 테이블에서 순차 스캔을 유발하는 인덱스 없는 쿼리 실행
- 특정 필드 대신 SELECT *로 모든 열 가져오기
- 인덱스 사용을 방지하는 선행 와일드카드와 LIKE 사용
자주 묻는 질문
어떤 열에 인덱스가 필요한지 어떻게 알 수 있나요?
N+1이란 무엇이며 어떻게 수정하나요?
부분 인덱스는 언제 사용해야 하나요?
Row-Level Security는 어떻게 작동하나요?
어떤 연결 풀 크기를 사용해야 하나요?
인덱스를 추가한 후 쿼리가 느린 이유는 무엇인가요?
개발자 세부 정보
작성자
sickn33라이선스
MIT
리포지토리
https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/postgres-best-practices참조
main