PostgreSQL(포스트그레스큐엘) 데이터베이스를 운영할 때 많은 연결을 효율적으로 관리하는 것은 오랜 숙제였습니다. 이 문제를 해결하기 위해 로컬 연결 풀, 짧은 연결 점유, 그리고 PgBouncer(피지바운서)와 같은 외부 연결 풀러를 함께 사용하는 방식이 업계 표준처럼 자리 잡았습니다. 최근 조사에 따르면, 18곳의 주요 관리형 PostgreSQL 제공업체 중 IBM Cloud(아이비엠 클라우드)와 OCI(오라클 클라우드 인프라스트럭처)를 제외한 16곳이 연결 풀러를 지원하며, 대다수가 PgBouncer를 기본 구성으로 제공하고 있습니다.
각 제공업체는 AWS(아마존 웹 서비스)의 RDS Proxy(알디에스 프록시), Supabase(수파베이스)의 PgBouncer 및 Supavisor(수파바이저)처럼 다양한 방식으로 연결 풀링을 구현합니다. 하지만 이러한 외부 풀러의 사용은 공급자와 사용자 모두에게 추가적인 복잡성을 야기합니다. 공급자는 PostgreSQL과 풀러를 함께 설치하고 설정하며, 별도의 접속 위치 규칙을 마련해야 합니다. 사용자 또한 PgBouncer의 listen/notify(리스닝/노티파이) 제한이나 풀링 모드별 장단점 등을 파악해야 하는 부담이 있습니다. 이는 마치 자동차를 구매한 후 앞유리를 별도로 장착해야 하는 상황과 비슷하여, 데이터베이스 운영의 효율성을 저해하는 요인으로 지적됩니다.
이러한 상황은 PostgreSQL에 연결 풀링 기능이 내장되어 있지 않기 때문에 발생합니다. MySQL(마이SQL)이나 MongoDB(몽고디비)와 같은 다른 데이터베이스 환경은 이미 하나의 URL(유알엘)과 포트만으로 연결 관리가 가능하여 사용자에게 훨씬 간편한 경험을 제공합니다. PostgreSQL 커뮤니티 내에서도 연결 풀링을 핵심 기능으로 재통합하려는 논의가 있지만, 오래된 프로세스 대 스레드 논쟁과 이를 주도할 영향력 있는 기여자의 부족으로 진전이 더딘 상황입니다. 만약 연결 풀링이 PostgreSQL 자체에 통합된다면, 수많은 개발자가 PgBouncer 우회에 투입했던 노력을 절감하고 운영 효율성을 크게 개선할 수 있을 것입니다. 이는 PostgreSQL의 가장 영향력 있는 개선 중 하나가 될 잠재력을 가지고 있습니다.