이 기사는 PostgreSQL을 사용 중인 애플리케이션에 ClickHouse를 추가하는 설계에 관한 메모입니다. Postgres를 교체하는 이야기가 아니라, 트랜잭션(Transaction)은 Postgres, 무거운 분석은 ClickHouse로 넘기는 구성을 생각합니다. 본문은 2026년 6월 8일에 확인한 ClickHouse 공식 블로그와 GitHub 정보를 바탕으로 하고 있습니다.

개인 개발이든 업무 시스템이든, 첫 번째 DB로 PostgreSQL을 선택하는 것은 자연스럽습니다.

사용자, 권한, 과금, 주문, 설정. 이런 데이터는 Postgres에 두고 싶습니다. 트랜잭션이 강하고, 주변 도구도 많으며, 애플리케이션에서 다루기 쉽기 때문입니다.

하지만 프로덕트가 성장하면 다른 것들이 늘어납니다.

• 이벤트 로그
• 감사 로그
• 검색 로그
• AI 추론 로그
• 대시보드용 집계
• 고객별 이용 상황
• 모델별 비용 및 레이턴시 (Latency)

여기까지 Postgres만으로 감당하려고 하면 점점 힘들어집니다.

처음에는 인덱스 (Index)를 추가합니다.

다음에는 집계용 테이블을 만듭니다.

그러다 보면 읽기 복제본 (Read Replica)을 만듭니다.

하지만 무거운 분석 쿼리 (Query)가 늘어나면, 앱 본체의 DB에 부하가 돌아옵니다.

그래서 "Postgres를 그만두고 ClickHouse로 옮긴다"라고 생각하면 이야기가 너무 커집니다.

제가 현실적이라고 생각하는 것은, Postgres를 버리지 않고 ClickHouse를 추가하는 구성입니다.

• Postgres와 ClickHouse는 경쟁 관계라기보다 역할 분담을 하기 쉽다
• Postgres는 트랜잭션의 기록 원천으로 남긴다
• ClickHouse는 대량 로그, 집계, AI 계열의 분석을 담당한다
• CDC로 Postgres의 변경 사항을 ClickHouse로 흘려보내면, 앱을 갑자기 새로 만들 필요가 없다
• pg_clickhouse를 사용하면, Postgres 측에서 ClickHouse의 분석 쿼리를 호출하는 선택지도 생겼다

Postgres는 강력한 DB입니다.

작은 앱이라면 한동안 Postgres만으로도 충분합니다. JSON도 다룰 수 있고, 인덱스도 풍부합니다. 분석용 SQL도 작성할 수 있습니다.

하지만 다음과 같은 쿼리가 늘어나면, 앱 본체의 DB로서는 힘들어집니다.

이런 처리는 정확성보다 "대량으로 읽어서 빠르게 집계하는 것"이 중요해집니다.

Postgres가 나쁜 것이 아닙니다. 역할이 다를 뿐입니다.

저라면 처음에 이렇게 나눕니다.

Postgres는 "정(正)"으로서 남겨둡니다.

ClickHouse는 "나중에 대량으로 읽는 장소"로서 추가합니다.

이렇게 나누면 앱의 중심을 급격하게 바꿀 필요가 없습니다. 기존의 Postgres를 지키면서 분석 부하만 ClickHouse로 넘길 수 있기 때문입니다.

ClickHouse 공식 블로그에서도 PostgreSQL은 트랜잭션의 기록 원천, ClickHouse는 분석을 담당한다는 조합이 소개되고 있습니다.1

Postgres의 데이터를 ClickHouse로 옮기는 방법은 여러 가지가 있습니다.

가장 알기 쉬운 것은 정기 배치 (Batch)입니다. 매시간, 매일, Postgres에서 데이터를 추출하여 ClickHouse에 넣습니다.

다만, 실시간에 가까운 분석을 하고 싶다면 CDC를 사용하고 싶어집니다.

CDC는 Change Data Capture의 약자로, DB의 변경 사항을 읽어 들여 다른 곳으로 흘려보내는 메커니즘입니다. Postgres에 들어온 변경 사항을 ClickHouse로 흘려보내면, 앱의 쓰기 대상은 Postgres로 유지하면서 분석용 데이터만 ClickHouse로 가져갈 수 있습니다.

ClickHouse Cloud에서는 ClickPipes의 Postgres CDC 커넥터 (Connector)가 GA (General Availability) 되었습니다. PeerDB가 ClickHouse Cloud에 통합되어, Postgres에서 ClickHouse로의 CDC를 지원하는 형태가 되었습니다.2

공식 회고 기사에서는 PeerDB가 2024년 7월에 ClickHouse에 인수되었으며, ClickPipes의 Postgres CDC 커넥터를 구동하는 엔진이 되었다고 설명하고 있습니다.3

CDC를 도입하면 아무것도 신경 쓰지 않아도 된다는 뜻은 아닙니다. 스키마 (Schema) 변경, 삭제, 중복 제거, 지연, 최초 로드, 장애 시 재개 등을 설계해야 합니다.

모든 것을 다 흘려보낼 필요는 없습니다.

오히려 처음에는 범위를 좁히는 것이 좋습니다.

반대로, 다음과 같은 것들은 신중하게 다뤄야 합니다.

ClickHouse는 대량의 데이터를 읽는 데 강점이 있습니다. 그곳으로 보낼 데이터를 선택하는 것이 중요합니다.

한 가지 더 살펴보고 싶은 것이 pg_clickhouse입니다.

pg_clickhouse는 PostgreSQL에서 ClickHouse 상의 데이터를 쿼리하기 위한 Postgres 확장(Extension)입니다. ClickHouse 공식 블로그에서는 Postgres 측의 SQL이나 애플리케이션 코드를 다시 작성해야 하는 부담을 줄이고, 분석 쿼리의 실행을 ClickHouse로 밀어내는(pushout) 것을 목표로 한다고 설명하고 있습니다.4

최초 공개 당시 버전은 v0.1.0이었습니다. GitHub의 README에 따르면 PostgreSQL 13 이상, ClickHouse v23 이상을 지원합니다. 2026년 6월 8일 기준, GitHub 상의 최신 릴리스는 v0.3.1입니다.5

이미지로 표현하자면, 다음과 같은 방식의 사용법입니다.

CREATE EXTENSION pg_clickhouse;
CREATE SERVER ch_analytics
FOREIGN DATA WRAPPER clickhouse_fdw
...

이를 통해 Postgres 측에서 ClickHouse의 테이블을 외래 테이블 (Foreign Table)로 볼 수 있게 됩니다.

물론 모든 것이 마법처럼 빨라지는 것은 아닙니다. pg_clickhouse는 분석 쿼리를 ClickHouse 측으로 푸시다운 (Pushdown) 하는 것을 목표로 하는 확장입니다. 푸시다운 되지 않는 처리는 Postgres 측으로 돌아올 가능성이 있습니다. 이 부분은 실제 쿼리를 통해 확인이 필요합니다.

Postgres와 ClickHouse를 조합한다면 크게 3가지 패턴이 있습니다.

처음부터 전부 다 넣을 필요는 없습니다.

작게 시작한다면, 우선 이벤트 로그를 직접 ClickHouse로 넣습니다. 그 후 Postgres의 주문이나 사용자 데이터가 필요해지면 CDC (Change Data Capture)를 고려합니다. 기존의 Postgres용 분석 SQL을 그대로 실행하고 싶다면 pg_clickhouse를 검증합니다.

이 순서가 현실적이라고 생각합니다.

AI 애플리케이션에서는 로그의 양이 늘어나기 쉽습니다.

사용자의 동작 한 번에 검색 (Search), 재순위화 (Rerank), 모델 호출 (Model Call), 도구 호출 (Tool Call), 평가 로그가 발생합니다. 모델을 바꾸면 비교하고 싶어지고, 프롬프트를 바꾸면 전후의 품질을 확인하고 싶어집니다.

Postgres에 모든 것을 다 넣으면, 애플리케이션 본체의 DB가 로그 저장소가 되어버립니다.

ClickHouse를 추가하면 다음과 같은 분석을 분리할 수 있습니다.

SELECT
model,
count() AS requests,
...

이것이 Postgres로는 절대 불가능하다는 뜻은 아닙니다.

하지만 로그가 계속해서 늘어난다면, 로그 분석에 적합한 DB로 분리하는 것이 애플리케이션 본체를 보호하기에 더 쉽습니다.

CDC로 Postgres의 변경 사항을 ClickHouse로 흘려보낼 때는, 중복 제거 (Deduplication)나 업데이트 표현을 어떻게 다룰지가 중요합니다.

ClickHouse의 Postgres CDC 회고 글에서도, Postgres 사용자가 ReplacingMergeTree의 동작을 이해하고, FINAL 구문이나 더 고도화된 패턴을 통해 중복 제거 (Deduplication)를 명시적으로 고민해야 한다고 설명되어 있습니다.3

즉, CDC로 흘려보냈다고 해서 Postgres와 완전히 같은 감각으로 읽을 수 있다고 생각해서는 안 됩니다.

예를 들어, 주문 데이터를 분석한다면 다음 사항들을 결정해야 합니다.

• ClickHouse 측에서는 최신 행(Row)만 보고 싶은가
• 업데이트 이력도 분석하고 싶은가
• 삭제를 어떻게 표현할 것인가
• FINAL을 사용하는 쿼리를 허용할 것인가
• 집계용 구체화된 뷰 (Materialized View)로 확정값을 만들 것인가

Postgres의 정규 데이터와 ClickHouse의 분석 데이터는 같은 것이 아닙니다. ClickHouse 측은 분석을 위한 투영 (Projection)으로 취급해야 사고를 방지하기 쉽습니다.

도입 전에, 다음 내용을 살펴보고 싶습니다.

• 어떤 테이블을 ClickHouse로 흘려보낼 것인가

• 개인정보나 비밀 정보를 흘려보내지 않도록 설계되어 있는가

• 업데이트 이력 (Update History)을 남길 것인가, 최신 상태만 볼 것인가

• 삭제를 어떻게 처리할 것인가

• ClickHouse 측의 ORDER BY를 어떻게 결정할 것인가

• 최초 로드 (Initial Load)에 시간이 얼마나 걸리는가

• 복제 지연 (Replication Lag)을 모니터링할 수 있는가

• 스키마 변경 (Schema Change)을 어떻게 처리할 것인가

• 장애 발생 시 어디서부터 재개할 수 있는가

• 하드 삭제 (Hard Delete)를 다룰 필요가 있는가

• 기존의 분석 SQL을 다시 작성할 것인가

• pg_clickhouse를 통해 우회할 수 있는 쿼리가 있는가 - 푸시다운 (Pushdown)되지 않는 쿼리를 어떻게 찾아낼 것인가

• FINAL이 필요한 쿼리를 파악하고 있는가 - 대시보드용 집계 테이블 (Aggregation Table)을 만들 것인가

• Postgres 측의 부하가 너무 커지지 않는가

• ClickHouse 측의 스토리지 (Storage)가 계속 늘어나지는 않는가

• 권한 관리 (Permission Management)를 Postgres와 ClickHouse에서 어떻게 나눌 것인가

• 감사 로그 (Audit Log)를 어느 정도 저장할 것인가

• 실패한 파이프라인 (Pipeline)을 누가 수정할 것인가

Postgres를 버릴 필요는 없습니다.

오히려 트랜잭션 (Transaction)이 중요한 부분은 Postgres에 남겨두는 것이 좋습니다. 사용자, 결제, 권한, 주문, 설정. 이 부분은 Postgres가 잘하는 영역입니다.

반면 로그, 집계, AI 요청, 검색 이력, 고객용 대시보드까지 Postgres 혼자서 모두 감당하려 하면 점점 힘들어집니다.

그래서 ClickHouse를 추가하는 것입니다.

Postgres는 정규 데이터 (Normalized Data)의 기록 원천. ClickHouse는 대량으로 읽는 분석 기반 (Analytics Infrastructure). CDC (Change Data Capture)로 다리를 놓습니다. 필요하다면 pg_clickhouse를 통해 Postgres 측에서 ClickHouse를 호출합니다.

이 구성은 화려하지 않습니다. 하지만 현실적입니다.

AI 시대의 DB 설계는 무엇이든 하나의 DB에 다 넣는 이야기가 아니게 되었습니다. Postgres를 지키기 위해 ClickHouse를 추가한다. 그렇게 생각하면 활용처가 보입니다.

• PostgreSQL + ClickHouse as the Open Source unified data stack | ClickHouse Blog ↩

• Postgres CDC connector for ClickPipes is now Generally Available | ClickHouse Blog ↩

• Postgres CDC in ClickHouse, A year in review | ClickHouse Blog ↩ ↩

2 -
Introducing pg_clickhouse: A Postgres extension for querying ClickHouse | ClickHouse Blog ↩