Supabase PostgreSQL Transaction Pooler 에러 해결

배경

Spring Boot 프로젝트를 배포할 일이 있어서 DB 서버를 알아보다 최근 많이 사용한 Supabase를 연결하려했다. PostgreSQL을 지원하기에 나중에 migration을 할때에도 수월할 것 같아 사용하게 되었다.

연동 방식은 아래 블로그 글을 참고하고 Transaction Pooler 모드로 연결을 진행했다. 참고 블로그

문제 상황

Spring Boot 애플리케이션에서 Supabase PostgreSQL을 Transaction Pooler 모드로 연결하던 중 다음과 같은 에러가 지속적으로 발생했다.

실제 에러 로그

배포된 AWS App Runner의 애플리케이션 로그

비슷하게 "S_1" already exists, "S_2" already exists 등의 에러도 함께 발생했다. S_x already exists 류의 에러 발생!

원인 분석

Transaction Pooler vs Session Mode

Supabase는 두 가지 연결 모드를 제공한다:

• Transaction Mode (포트 6543): 연결을 여러 클라이언트가 공유하여 효율적인 자원 사용
• Session Mode (포트 5432): 각 클라이언트가 독점적인 연결을 유지

PostgreSQL JDBC Driver의 Prepared Statement 캐싱

PostgreSQL JDBC Driver는 기본적으로 Server-side Prepared Statements를 사용한다:

1. prepareThreshold 기본값은 5
2. 같은 쿼리가 5번 실행되면 서버에서 prepared statement를 생성
3. 이때 S_1, S_2, S_3 같은 이름으로 statement가 저장됨

문제의 핵심

Transaction Pooler 모드에서는 여러 클라이언트가 같은 데이터베이스 연결을 공유하는데, 각 클라이언트가 같은 이름의 prepared statement를 생성하려고 시도하면서 충돌이 발생한다.

Client A: CREATE PREPARED STATEMENT "S_1" ...
Client B: CREATE PREPARED STATEMENT "S_1" ...  # 충돌!

해결 방법

진리의 문 stackoverflow에 답이 있었다… 간단한 수정으로 해결했으며 아래에 기술하겠다!

1. prepareThreshold=0 설정

가장 간단한 해결책은 server-side prepared statements를 비활성화하는 것이다.

application.yml 설정

spring:
  datasource:
    url: jdbc:postgresql://aws-0-us-west-1.pooler.supabase.com:6543/postgres?prepareThreshold=0
    username: postgres.your-project-ref
    password: your-password
    driver-class-name: org.postgresql.Driver

2. 포트 변경 고려

Transaction Pooler 모드(6543)에서 Session Mode(5432)로 변경하는 것도 해결책이 될 수 있다. supabase공식문서

spring:
  datasource:
    url: jdbc:postgresql://aws-0-us-west-1.pooler.supabase.com:5432/postgres
    username: postgres.your-project-ref
    password: your-password

하지만 이 경우 Connection Pool의 이점을 잃게 된다.

성능 고려사항

prepareThreshold=0의 영향

• 장점: Transaction Pooler와의 호환성 보장
• 단점: Prepared Statement 캐싱 비활성화로 인한 약간의 성능 저하

결론

Supabase PostgreSQL Transaction Pooler와 Spring Boot를 연결할 때는 prepareThreshold=0 설정이 필요하다. 이는 PostgreSQL JDBC Driver의 server-side prepared statement 캐싱 기능과 Transaction Pooler의 연결 공유 방식 간의 충돌을 해결한다.

성능상 약간의 손실이 있을 수 있지만, 안정적인 연결을 위해서는 필요한 트레이드오프로 잘 고려해서 사용하자…

참고 자료

• PostgreSQL JDBC Server Prepared Statements
• Supabase Connection Pooling Guide