핵심 내용
GeekNews 최신 글 페이지에서 9월 16일 오전 기준 개발 실무와 직접 연결되는 신규 항목으로 pg_chdb가 올라왔다. GeekNews 요약만 사용하지 않고 ClickHouse의 원본 GitHub 저장소를 확인했다. pg_chdb는 PostgreSQL 확장으로, embedded ClickHouse 계열인 chDB를 호출해 Postgres 안에서 외부 데이터를 분석하거나 PostgreSQL 테이블로 가져올 수 있게 한다.
chdb_query()로 S3 같은 외부 저장소의 CSV·Parquet·JSON 등을 ClickHouse SQL로 조회할 수 있고, chdb_hook은 PostgreSQL의 COPY 명령을 확장해 S3, Google Cloud Storage, Azure Blob, 로컬 파일, HTTP URL에서 데이터를 직접 가져오거나 내보낼 수 있게 한다. 프로젝트 문서가 제시한 benchmark에서는 약 100만 행의 NYC Taxi 데이터를 대상으로 CSV·JSON·Parquet import 시 pg_duckdb와 pg_lake보다 대략 2~3배 빠른 결과를 제시하지만, 이는 프로젝트 자체 benchmark이므로 환경에 따라 달라질 수 있다.
구조적으로는 chdb_helper라는 별도 프로세스가 ClickHouse 작업을 수행하며 PostgreSQL shared memory를 사용하지 않는다. helper가 죽어도 전체 Postgres 서버보다 해당 backend에만 오류가 전달되도록 격리한 설계다. 반면 현재는 각 query가 디스크의 임시 chDB database에서 완전히 독립적으로 실행되므로, 한 chDB query에서 만든 table을 다음 query에서 다시 사용하는 식의 상태 유지가 되지 않는 제약이 있다.
배경
PostgreSQL을 운영DB로 쓰면서 데이터레이크의 Parquet나 대형 CSV를 조회하려면 별도 ETL, DuckDB 확장, FDW, 외부 분석DB 같은 여러 선택지가 있다. pg_chdb는 ClickHouse의 format·storage connector와 vectorized execution을 PostgreSQL 옆에 붙여, 드물게 수행하는 대량 import나 외부 파일 분석을 메인 Postgres 프로세스와 격리하는 접근이다.
산업·시장 영향
운영DB와 분석엔진의 경계가 점점 얇아지고 있다. PostgreSQL 생태계에서 DuckDB 계열 확장과 ClickHouse 계열 확장이 경쟁하면, 사용자는 데이터를 별도 warehouse로 복제하지 않고도 S3·Parquet 기반 분석을 애플리케이션 DB 가까이에서 처리할 수 있다. 다만 OLTP workload와 대형 scan을 같은 서버 자원에서 섞을 경우 resource contention을 관리해야 한다.
실무에서 바로 활용할 시사점
PostgreSQL 서비스에서 ‘가끔 수GB~수십GB짜리 Parquet를 읽어 테이블로 적재한다’거나 S3 원본을 빠르게 확인하는 업무가 있다면 POC 가치가 있다. production 도입 전에는 helper의 CPU·memory limit, transaction semantics, 실패 시 재처리, 권한과 외부 URL 접근통제를 테스트해야 한다. 특히 사용자가 임의 URL을 query할 수 있게 노출하면 SSRF나 데이터 반출 경로가 될 수 있으므로 query interface는 내부 신뢰영역에 제한하는 편이 안전하다.