PostHogがDuckDBをやめTrinoに移った理由｜PBスケールで当たった3つの壁

アナリティクス基盤の PostHog が、自社のデータウェアハウスを短期間で二度作り直した経緯を公開した。共有 ClickHouse から5か月前に DuckDB ＋ DuckLake へ、そして今回、わずか3か月の再設計で Trino ＋ 自作の HogLake へ——という流れだ。この記事は、PostHog のエンジニアリングブログ（Benjamin Knofe-Vider 氏）を出典に、PostHog の DuckDB 事例から読み取れる3つの壁を、中立に整理する。先に言っておくと、これは「DuckDB はダメ」という話ではなく、単一ノードの名器を、PBスケールのマルチテナント・クラウド倉庫に仕立てる難しさの話だ。

AI 関連ではない純粋なデータ基盤の事例だが、分析ウェアハウスは ML/分析の土台として多くの開発者に関わる。似た「自作に踏み切った」話として、当サイトではMojo 言語の破壊的変更なども扱っている。

DuckDBは1台なら最高、クラウドでは事前にサイズを決める難しさ

PostHog はまず DuckDB を全面的に称賛する。1台で大量のデータを分析する最良級の単体エンジンで、その「1台」は手元のノートPCでもいい。堅牢で、ほぼ必ずクエリを完走し、メモリが足りなければディスクに退避（spill）する——ローカルでは完璧に近い。

問題は、同じ長所がクラウドでは裏目に出た点だと言う。顧客は想定以上に複雑なクエリを流し、PostHog は巨大インスタンスを足すことになった。ディスクを足す手もあったが、クエリが遅く高価になりすぎて現実的でない。単一ノードのエンジンをクラウドで安全に動かすには、クエリが来る前にワーカーのサイズを決めておく必要がある。ここが厄介で、「あなたのクエリにはどれだけのリソースが要る」と顧客に伝える良い方法が見つからず、特定クエリのCPU・メモリを事前に読むのはさらに難しかった。利用者はそんなことを気にすべきではない——必要なものを流せばよく、残りをさばいて予測可能にするのが運営側の仕事だ、というのが同社の立場だ。加えて、S3から大量データを非同期で取得する仕組みが当時の DuckDB には無く（最近追加された）、これもボトルネックになった。

DuckLakeは互換性優先で、スケール設計ではない

DuckDB を本格的なウェアハウスにするため、PostHog は DuckLake 拡張を既定で入れた。DuckDB と同じ作者陣による新しいレイクハウス形式で、「簡素に、ほぼどんな構成でも動く」という DuckDB の思想を継ぐ。ある規模まではうまく動くが、PostHog の規模では最初から分散スケール向けに設計されたものが必要だった、という。

核心は、DuckLake のカタログスキーマが多数のSQLデータベース間で可搬であり続けねばならないため、エンジン固有の最適化が制限されることだ。PostHog の規模では、単一テーブルへの書き込み一回が3分以上かかることがあった。コミットのたびにカタログ全体の統計を読み直すためだ。さらに、カタログの統計行の99%以上が、もう存在しないテーブルのものだった。掃除すると書き込みが30〜50倍速くなったが、行はまた増え続けた。メタデータDBへ開く接続数も問題で、共有 Postgres インスタンスでは1接続ごとに実コストがかかる。DuckLake を使い続けるには「公式」スキーマと100%互換でいる必要があり、最適化の選択肢はさらに狭まった。結局、必要な速さで変更を取り込めずフォークでパッチを抱えることになり、DuckLake を使う最大の利点であるコミュニティの恩恵を自ら手放す形になった、と振り返っている。ここは OSS を基盤に据えるときの一般的な教訓でもある。自社の要求が上流の設計方針（ここでは「可搬性を保つ」）と食い違い、かつ変更を本家に取り込んでもらう速度が足りないと、フォーク維持のコストが積み上がる。可搬性と最適化はテーブルフォーマット設計の本質的なトレードオフで、どちらを取るかは「誰のための、どの規模の倉庫か」で変わる——PostHog は後者（最適化）を取れる自前フォーマットへ舵を切った、という整理になる。

Postgres接続（pgwire）のスケールは見た目より難しい

もう一つの壁が、ポート5432での直接 Postgres 接続だ。dbt などが素直に繋げるので良いアイデアに見えたが、実運用では HTTP よりずっとスケールが難しかったという。再接続の実装、TTLやアイドル接続の管理が大変で、長命の接続はコストが高い。pgwire はHTTPに比べてロードバランスの道具が乏しい（AWSの NLB と ALB の使い勝手の差がそのまま効く）。Kubernetes でのルーティングも、HTTP ヘッダが使えるHTTPの方が柔軟だ。

さらに、Postgres クライアントは無数にあり、それぞれが独自の挙動を期待する。「このクライアントを直してほしい」という要望が絶えず、多くの修正を出したがカバレッジは十分にならなかった。Postgres 互換のロングテールを延々追うより、優れたウェアハウスを作ることに時間を使いたい——というのが、ここから降りた理由だ。

では、いつDuckDB/DuckLakeを選ぶべきか

PostHog の壁は「PBスケールのマルチテナント・クラウド倉庫」という特定の文脈で出たものだ。だから、この事例を「DuckDB は使うな」と一般化するのは正しくない。むしろ線引きの材料として読むのがいい。

向くのは、単一ノードで収まる規模の分析だ。手元のノートPCやひとつのサーバで、数GB〜数百GB、せいぜい単機のメモリとディスクで捌ける範囲なら、DuckDB は起動も速く依存も少なく、第一候補になる。ETLの中間処理、アドホックな分析、ダッシュボードの裏側、CI での小さなデータ検証——このあたりは DuckDB の独壇場だ。DuckLake も、可搬性が効く小〜中規模のレイクハウスや、複数の実行環境から同じテーブルを読む用途では利点が勝つ。

逆に、事前にサイズを読めない多様なクエリを、多数のテナント向けに、PB級で、他人のために運用する——という条件が重なると、単一ノード前提と可搬性優先のカタログは足かせになりやすい。PostHog が降りたのはまさにこの交点で、同じ条件に当てはまるなら、最初から分散前提の Trino やそれに類する選択肢を検討する価値がある。要は「自分の規模と運用形態が、単一ノードの前提に収まるか」を先に見極めることだ。

Trino＋HogLakeへ、そして持ち帰り

PostHog は、独自色の Trino と、自作のオープンなテーブルフォーマット HogLake で全面的に作り直していると公表した。最初から分散スケール前提で、まず自社のPBスケールで固めてから設計パートナーに渡す、という進め方だ。同社は「ウェアハウスの裏の技術を誇張しすぎない。大事なのは使い手の体験」とも書いており、技術選定自体より「どんな規模でも公正な価格で動く体験」を目標に据えている。

この事例から、他の人が持ち帰れる線引きを表にまとめる。

参照ソース

• PostHog Engineering — Why we rebuilt our warehouse off DuckDB（本記事の出典。Benjamin Knofe-Vider 氏。PBスケールでの DuckDB/DuckLake の壁と Trino/HogLake への移行。数値はPostHog自身の報告値で、一次のブログ本文はこのセッションから未取得）
• DuckDB 公式（単一ノード分析エンジン）／DuckLake（DuckDB 作者陣のレイクハウス形式）
• Trino 公式（分散SQLクエリエンジン。PostHog の新基盤の土台）