ClickHouse vs DuckDB, 단일 노드 적용 경계

이번 분석에서는 ClickHouse와 DuckDB가 단일 노드에서 서로의 영역을 어디까지 대신할 수 있는지를 공개 벤치마크 자료만으로 추려봤다. 결론부터 말하면 두 엔진 모두 "빠르다"는 근거는 각자 있지만, 동일 조건에서 직접 맞붙은 재현 가능한 수치는 2026년 기준으로도 확인되지 않는다. 판단은 속도가 아니라 수집 지속성·동시성·머티리얼라이즈드 뷰 유지 여부라는 축으로 갈라야 한다.

ClickHouse와 DuckDB, 단일 노드에서 어디까지 같은 용도로 쓸 수 있나?

단일 노드라는 조건만 놓고 보면 두 엔진은 파일 스캔·집계 구간에서 상당 부분 겹치지만, 지속적인 이벤트 수집과 머티리얼라이즈드 뷰 유지까지 포함하면 겹치는 구간은 눈에 띄게 좁아진다.

• DuckDB v1.4 LTS의 인메모리 변형은 2025년 10월 ClickBench 1위를 기록했지만, 이는 콜드 런·핫 런·동시성 조건을 분리하지 않은 단일 결과다. DuckDB 공식 발표
• ClickHouse는 수집 비용과 질의 비용을 별도 지표로 측정하는 벤치마크 체계를 공식 제공한다. ClickBench
• 두 엔진을 동일 버전·동일 하드웨어·동일 입력 배치로 비교한 1차 자료는 현재 공개돼 있지 않다.
• "ClickHouse가 항상 빠르다"나 "DuckDB는 스트리밍 수집에 부적합하다" 같은 단정은 지금 확인 가능한 자료로는 뒷받침되지 않는다.

두 선택지를 나란히 놓으면 구조 차이가 먼저 보인다. DuckDB는 프로세스에 임베디드되는 분석 엔진으로, 파일(Parquet·CSV 등)이나 로컬 데이터셋을 즉석에서 스캔·집계하는 흐름에 맞춰져 있다. ClickHouse는 독립 서버 프로세스로 동작하며, 유입되는 이벤트를 계속 받아 쌓으면서 동시에 질의를 처리하는 상주형 구조다. 이 구조 차이가 아래 축별 비교의 출발점이다.

이벤트 수집 처리량은 두 엔진에서 어떻게 갈리나?

수집 처리량 비교는 현재 공개 자료만으로는 완결되지 않는다. ClickHouse는 2025년 입력 포맷 벤치마크에서 서버 측 수집 비용을 별도로 분리해 측정했고, 측정 항목에 처리 시간·CPU 사용량·메모리 사용량·파일 크기를 포함시켰다. 테스트 변수에는 입력 포맷, 배치 크기, 압축 방식, 사전 정렬 여부가 들어갔다. ClickHouse 벤치마크 회고

이 자료가 주는 실질적인 시사점은 숫자 자체가 아니라 측정 설계다. 이벤트 스트림 수집 성능을 "초당 몇 행"으로 단순화하면 조건이 빠진 수치가 된다. 포맷이 JSON인지 Parquet인지, 배치가 한 건씩 들어오는지 묶음으로 들어오는지, 압축을 어느 단계에서 거는지, 사전 정렬 여부에 따라 같은 엔진 안에서도 결과가 크게 갈린다. DuckDB 쪽은 동일한 조건으로 수집 비용만 분리해 측정한 공식 자료가 검색 결과에 나타나지 않는다. 따라서 "DuckDB가 수집에서 느리다"는 주장도, "ClickHouse가 수집에서 항상 유리하다"는 주장도 지금 단계에서는 근거가 부족하다.

콜드 런과 핫 런, ClickBench 수치는 그대로 믿어도 되나?

그대로 믿기는 어렵다. ClickBench 공식 페이지는 Cold Run, Hot Run, Load Time, Storage Size, Concurrent QPS를 서로 다른 지표로 나눠 제공한다. ClickBench 어느 엔진이 빠르다고 쓰려면 최소한 캐시 상태, 저장 형식, 로드 시간 포함 여부, 동시성, 하드웨어 스펙을 함께 명시해야 결과가 의미를 갖는다.

DuckDB v1.4 LTS의 1위 기록은 이 중 인메모리 변형을 기준으로 한다. 검색 결과에는 구체적인 CPU, 메모리, 데이터셋 크기, 쿼리별 실행 시간, 동시성 조건이 드러나지 않는다. 즉 "DuckDB가 ClickBench 1위"라는 문장은 사실이지만, 그 문장만으로 지속적인 이벤트 수집, 장애 복구, 고동시성 서비스, 머티리얼라이즈드 뷰 유지까지 검증됐다고 확장해서는 안 된다. ClickHouse 쪽은 버전별 벤치마크 페이지를 별도로 운영하며 릴리스 간 변화를 추적하지만, 이 역시 ClickHouse 내부 비교이지 DuckDB와 동일 조건 비교는 아니다. 버전별 벤치마크

머티리얼라이즈드 뷰와 JOIN 처리 방식은 왜 다른가?

ClickHouse는 모델링 선택지 자체를 넓은 비정규화 테이블, 수집 시 JOIN을 수행하는 머티리얼라이즈드 뷰, 정규화된 스타 스키마로 구분해서 설명한다. 2025년 자료의 TPC-H 실험은 32코어 AWS 인스턴스, 메모리 128GiB, 스케일 팩터 100, 약 6억 행 팩트 테이블 조건으로 수행됐다. ClickHouse and Joins 이 조건은 JOIN 처리와 데이터 모델링 선택을 설명하는 사례로는 쓸 수 있지만, 수집 처리량이나 머티리얼라이즈드 뷰 유지 비용까지 수치로 확인해 주지는 않는다.

ClickHouse 25.1에서는 dbt가 Refreshable Materialized View를 지원하게 되면서, 수집 시 즉시 변환하는 증분형 머티리얼라이즈드 뷰와 주기적으로 결과만 갱신하는 방식을 구분해 다룰 필요가 생겼다. 25.1 릴리스 자료 25.11 변경 내역에는 optimize_read_in_order와 query_plan_optimize_lazy_materialization을 함께 쓸 수 있게 된 항목이 있는데, 이는 특정 읽기·실행 계획에서 불필요한 컬럼 구체화를 늦추는 최적화와 관련된다. 2025 변경 내역 다만 이 변경만으로 일반적인 이벤트 집계 지연시간이 얼마나 줄었는지는 수치화돼 있지 않다. DuckDB는 단일 프로세스 안에서 쿼리를 즉석에서 실행하는 구조에 가까워, 수집 시점에 JOIN을 미리 수행해 두는 증분형 뷰 개념 자체가 ClickHouse만큼 운영 문서로 정리돼 있지 않다.

지금까지 확인된 수치를 표로 정리하면?

이 표는 "어느 쪽이 빠르다"를 보여주기 위한 것이 아니라, 각 엔진이 공개한 측정 축 자체가 다르다는 점을 보여주기 위한 것이다.

ClickHouse에서 DuckDB로, 혹은 반대로 옮기면 무엇이 드나?

전환 비용은 대부분 측정 체계를 다시 세우는 작업에서 나온다. ClickHouse에서 DuckDB로 옮긴다면 지속 수집 파이프라인을 파일 기반 배치 적재로 다시 설계해야 하고, 증분형 머티리얼라이즈드 뷰가 맡던 수집 시 JOIN·집계를 별도 스케줄링 레이어로 옮겨야 한다. 파티션 키·정렬 키·압축 설정처럼 ClickHouse 저장 엔진에 맞춰 튜닝된 값은 DuckDB의 파일 레이아웃(Parquet 파티셔닝 등)으로 다시 설계해야 한다.

반대로 DuckDB에서 ClickHouse로 옮긴다면 단일 프로세스 임베디드 환경에서 상주형 서버 운영으로 바뀌면서, 수집 지연·동시 질의 수·캐시 상태별 지연시간(p50·p95·p99)을 처음부터 다시 측정해야 한다. 어느 방향이든 기존에 한쪽 엔진 기준으로 고정했던 배치 크기, 입력 포맷, 압축 방식, 정렬 조건을 상대 엔진의 측정 축에 맞춰 다시 수집해야 전환 전후 비교가 의미를 가진다.

그래서 어느 쪽을 골라야 하나?

정답은 엔진 자체가 아니라 운영 조건에 있다. 단일 프로세스·단일 노드에서 파일이나 로컬 데이터셋을 반복 스캔·집계하는 용도라면 DuckDB의 공식 벤치마크가 직접적인 근거가 된다. 지속적으로 유입되는 이벤트를 저장하면서 대규모 GROUP BY, 실시간 질의, 입력 포맷·압축·배치 최적화를 함께 운영해야 한다면 ClickHouse의 공식 벤치마크와 기능 자료가 더 가까운 근거를 제공한다.

다만 실제 적용 판단에는 양쪽 모두 배치 크기, 파티션·정렬 키, 압축 방식, 머티리얼라이즈드 뷰 개수, 캐시 상태, 동시 질의 수를 반드시 함께 기록해야 한다. 이 조건들이 고정되지 않은 비교는 어느 쪽으로도 결론을 낼 수 없다.

핵심 정리

• DuckDB v1.4 LTS 인메모리 변형의 ClickBench 1위 기록은 사실이지만 캐시·동시성 조건이 분리돼 있지 않아 운영 전반의 우열 근거로는 부족하다.
• ClickHouse는 수집 비용과 질의 비용, 콜드/핫 런을 별도 지표로 공개하지만 이는 ClickHouse 내부 비교이며 DuckDB와 동일 조건 비교는 아니다.
• 수집 처리량 비교는 입력 포맷·배치 크기·압축·정렬 조건을 고정하지 않으면 의미가 없다.
• 머티리얼라이즈드 뷰는 증분형과 Refreshable로 구분해야 하며, ClickHouse 25.1·25.11 자료는 기능 변경이지 처리량 수치는 아니다.
• 전환 비용은 속도 차이가 아니라 수집 파이프라인·측정 체계를 다시 세우는 작업에서 대부분 발생한다.

자주 묻는 질문

단일 노드 ClickBench 1위 결과만으로 DuckDB를 실시간 수집 엔진으로 써도 되나?

그 결과만으로는 판단하기 어렵다. 해당 기록은 인메모리 변형 기준이며 지속적인 이벤트 수집, 장애 복구, 머티리얼라이즈드 뷰 유지 조건을 검증한 자료가 아니기 때문이다.

ClickHouse의 입력 포맷 벤치마크 수치를 바로 인용해도 되나?

원문 표를 직접 확인한 뒤 인용해야 한다. 검색 결과에는 포맷·배치·압축·정렬 조합별 개별 수치가 노출되지 않아, 일반화된 숫자로 재인용하면 조건이 빠진 수치가 된다.

두 엔진을 같은 조건에서 비교하려면 최소 무엇을 고정해야 하나?

버전, CPU·RAM·저장장치, 원시 이벤트 행 수와 입력 포맷, 배치 크기와 초당 입력량, 압축·정렬·파티션 조건, 머티리얼라이즈드 뷰 개수와 변환 SQL, 콜드·웜 캐시 여부, p50·p95·p99 질의 지연을 함께 고정해야 한다.

ClickHouse의 대규모 GROUP BY 확장 실험을 단일 노드 성능 근거로 써도 되나?

안 된다. 해당 실험은 ClickHouse Cloud의 분산 실행과 병렬 리플리카 확장을 다룬 자료로, 단일 노드 성능이나 DuckDB와의 비교 근거로는 적합하지 않다.

더 알아보기

실시간 분석 엔진: 아키텍처와 설계 판단 — 이 주제의 종합 가이드