PostHog, 고객용 데이터 웨어하우스를 DuckDB에서 Trino·HogLake로 재설계
PostHog는 고객용 데이터 웨어하우스의 실행 기반을 Trino와 HogLake로 재구성했습니다. 단일 노드 DuckDB는 대형 쿼리에 필요한 자원을 미리 잡아야 했고, DuckLake의 카탈로그 커밋은 전체 통계를 읽느라 느려졌습니다. ClickHouse는 주력 제품 분석에 계속 쓰이며 새 구성은 PostHog 규모에서 시험 중입니다.

본문
PostHog는 고객용 데이터 웨어하우스의 실행 기반을 DuckDB에서 분산 SQL 엔진 Trino와 자체 테이블 형식 HogLake로 재구성했습니다. PostHog Engineering Blog의 Benjamin Knofe-Vider는 2026년 11월 2일 글에서 고객 쿼리의 규모와 복잡도를 예상보다 낮게 잡았고, 대형 단일 노드와 DuckLake 카탈로그 쓰기가 병목이 됐다고 설명했습니다. Hacker News에서 창업자라고 밝힌 timgl은 이 웨어하우스가 주력 분석 데이터베이스와 분리된 제품이라고 덧붙였습니다. ClickHouse는 제품 분석을 계속 맡고, DuckDB 기반 웨어하우스는 소수 파일럿 고객이 사용했습니다.
PostHog는 2026년 6월 29일 웨어하우스를 ClickHouse에서 DuckDB로 바꾼다고 발표했습니다. 당시 공유 ClickHouse 클러스터는 몇 시간씩 실행되는 데이터 모델링 쿼리를 처리하기 어려웠고, PostHog는 고객마다 별도의 DuckDB 인스턴스를 두는 방식으로 전환했습니다. 각 고객의 작업을 나누고 데이터 도구가 익숙한 PostgreSQL 호환 연결을 제공했으며, DuckLake 카탈로그를 통해 데이터 파일은 S3에 두고 계산 엔진과 저장소를 분리했습니다.
이 구조는 고객 쿼리가 예상보다 크고 복잡해지면서 한계에 부딪혔습니다. DuckDB는 한 대의 컴퓨터에서 대용량 데이터를 분석하고, 메모리가 모자라면 디스크를 쓰면서 쿼리를 끝내는 데 강점이 있습니다. 하지만 클라우드에서 단일 노드 엔진을 안전하게 운영하려면 쿼리가 도착하기 전에 worker의 크기를 정해야 합니다. 고객이 어떤 CPU와 메모리를 필요로 할지 예측하기 어렵고, 디스크를 더 붙이면 쿼리가 느려지고 비용이 커졌습니다. 글 작성자라고 밝힌 roboben은 Hacker News 댓글에서 많은 고객 Pod가 46 vCPU와 360GB 메모리로 돌아가면서도 추가 자원을 요청했다고 설명했습니다.
병목은 DuckDB의 쿼리 실행뿐 아니라 DuckLake의 카탈로그 쓰기에서도 나왔습니다. PostHog 설명에 따르면 DuckLake는 여러 SQL 데이터베이스에서 쓸 수 있도록 카탈로그 구조를 이식성 있게 유지합니다. 그만큼 Postgres에 특화한 최적화를 넣기 어려웠고, 대규모 환경에서는 테이블 하나를 쓰는 커밋이 카탈로그 전체의 통계를 다시 읽느라 3분 넘게 걸리기도 했습니다. 카탈로그 통계 행의 99% 이상은 이미 사라진 테이블에 속했습니다. 이 행을 정리하면 쓰기가 30~50배 빨라졌지만 통계가 다시 쌓였습니다. 공유 Postgres 데이터베이스에 DuckLake가 여는 메타데이터 연결도 운영 부담을 키웠습니다.
새 구조에서 Trino와 HogLake는 서로 다른 역할을 맡습니다. Trino는 SQL 질의를 여러 자원에 분산해 실행하는 엔진입니다. 글 작성자라고 밝힌 roboben은 필요한 자원을 더 유연하게 배정할 수 있다는 점을 Trino의 장점으로 설명했습니다. HogLake는 데이터 파일과 카탈로그를 관리하는 서비스입니다. 공개 저장소 README에 따르면 작성자는 Parquet 파일을 오브젝트 스토리지에 올린 뒤 파일 경로와 통계를 HogLake에 등록합니다. HogLake는 스냅샷과 스키마 등 카탈로그 정보를 Postgres에 기록하고, Trino 커넥터는 카탈로그에서 쿼리할 파일 정보를 얻어 데이터를 읽습니다.
HogLake README는 커밋을 바뀐 데이터 집합에 한정해 처리하도록 설계했다고 설명합니다. DuckLake에서 문제가 된 카탈로그 전체 통계 재조회 대신 각 변경분을 중심으로 커밋 비용을 관리하려는 구조입니다. 이전 웨어하우스가 제공한 PostgreSQL 호환 연결도 PostHog가 꼽은 운영 문제였습니다. 장기 연결과 재접속, 유휴 연결 만료, 여러 PostgreSQL 클라이언트의 호환성을 대규모로 관리하기 어려웠고, 회사는 HTTP가 Kubernetes에서 부하를 분산하기 수월했다고 밝혔습니다. HogLake의 공개 설계 문서는 메타데이터 접근에 REST 계약을 둡니다.
PostHog는 새 구성을 자체 페타바이트 규모에서 시험한 뒤 설계 파트너에게 제공하겠다고 밝혔습니다. 블로그에는 Trino·HogLake와 이전 구성을 같은 쿼리로 비교한 처리시간이나 비용 수치가 없습니다. 따라서 공개된 내용은 전환 이유와 새 시스템의 설계, 내부 시험 단계까지를 설명합니다.
자료: PostHog Engineering Blog, PostHog/HogLake GitHub, Hacker News / 정리·해설: Trawling
참고 자료
- Why we're moving our warehouse off DuckDB
- Why we rebuilt our data warehouse and how it unlocks self-driving products
- Moving our warehouse off DuckDB | Hacker News
- GitHub - PostHog/hoglake: Petabyte-scale open table format, an evolution of Ducklake and Iceberg · GitHub
- hoglake/docs/trino-integration.md at main · PostHog/hoglake · GitHub