PostgreSQL 성능 튜닝 실전 가이드

한 줄 요약: PostgreSQL 성능 튜닝의 80%는 인덱스 설계, 쿼리 최적화, 커넥션 풀 설정에서 결정된다.

PostgreSQL은 기본 설정만으로도 잘 동작하지만, 트래픽이 늘면 느려지기 시작한다. 이 가이드는 실전에서 가장 효과적인 성능 튜닝 전략을 단계별로 정리한다.

느린 쿼리 찾기

성능 개선의 첫 단계: EXPLAIN ANALYZE. 이 명령으로 쿼리 실행 계획을 확인하고, Seq Scan(전체 스캔)이 발생하는 곳을 찾습니다.

EXPLAIN ANALYZE는 성능 진단의 시작점이다. 느린 쿼리에 EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)를 붙여 실행 계획을 확인한다. Seq Scan(전체 스캔)이 보이면 인덱스 부족, Nested Loop가 대량 데이터에 사용되면 JOIN 전략 변경이 필요하다.

EXPLAIN ANALYZE 실전 예시
EXPLAIN (ANALYZE, BUFFERS)
SELECT u.name, COUNT(o.id)
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE o.created_at > '2026-01-01'
GROUP BY u.name
ORDER BY COUNT(o.id) DESC
LIMIT 10;

-- Seq Scan on orders가 보이면:
CREATE INDEX idx_orders_user_created
ON orders (user_id, created_at);

인덱스 설계 원칙: WHERE 절에 자주 사용되는 컬럼에 인덱스를 만든다. 복합 인덱스는 카디널리티가 높은 컬럼을 앞에 배치한다. 부분 인덱스(WHERE is_active = true)로 인덱스 크기를 줄인다. 사용되지 않는 인덱스는 INSERT/UPDATE 성능을 저하시키므로 정기적으로 제거한다.

인덱스 전략

인덱스는 만능이 아닙니다. 자주 검색하는 컬럼에 만들되, INSERT/UPDATE가 많은 테이블에서는 인덱스가 오히려 성능을 떨어뜨릴 수 있습니다. 복합 인덱스의 컬럼 순서가 중요합니다.

모니터링 도구

추천 모니터링 도구: pg_stat_statements(쿼리 통계), pgBadger(로그 분석), Datadog/Grafana(실시간 대시보드).

커넥션 풀 최적화

PostgreSQL의 기본 max_connections은 100이다. 서버리스 환경(Vercel, Lambda)에서는 각 함수 인스턴스가 커넥션을 생성하므로, 순식간에 한도에 도달한다. PgBouncer(커넥션 풀러)를 사이에 두면 수천 개의 요청을 수십 개의 실제 커넥션으로 처리할 수 있다. Supabase, Neon 등은 PgBouncer를 기본 포함한다.

핵심 설정 튜닝

서버 메모리 16GB 기준 권장 설정: shared_buffers = 4GB(전체 RAM의 25%), effective_cache_size = 12GB(전체 RAM의 75%), work_mem = 64MB(복잡한 정렬/해시에 사용), maintenance_work_mem = 1GB(VACUUM/CREATE INDEX에 사용). PGTune 도구로 서버 사양에 맞는 설정을 자동 생성할 수 있다.

운영 팁: pg_stat_statements 확장을 활성화하면 가장 많이 실행되거나 가장 느린 쿼리를 자동으로 추적할 수 있다. 주기적으로 상위 10개 쿼리를 확인하고 최적화하라.

느린 쿼리 찾기

인덱스 전략

모니터링 도구

커넥션 풀 최적화

핵심 설정 튜닝

관련 포스트