PostHog: Clickhouse > DuckDB > Trino.

Apa konteks evolusi data warehouse PostHog?

Evolusi data warehouse PostHog pada 2026 menunjukkan bahwa satu mesin tidak selalu cocok untuk semua skala. Layanan Managed Warehouse berpindah dari ClickHouse bersama ke DuckDB terisolasi per tenant, lalu ke Trino terdistribusi dengan format tabel HogLake. Perubahan ini menyeimbangkan kemudahan pengembang, isolasi beban, kompatibilitas SQL, dan kebutuhan join analitik pada lebih dari 2 PB data.

Kejujuran rekayasa lebih penting daripada dogma teknis.

PostHog menguji mesin-mesin ini sambil menggunakan infrastrukturnya sendiri pada beban internal berskala besar: lebih dari 2 petabita data, sekitar 1 triliun baris, dan 15,3 juta snapshot. Migrasi dari ClickHouse ke DuckDB pada pertengahan 2026 meningkatkan pengalaman pengembang dan kompatibilitas ekosistem.

Namun, ketika eksekusi satu node dan spesifikasi katalog yang masih berkembang didorong hingga satu triliun baris, platform itu melampaui batas rekayasanya. Pada awal November 2026, kebutuhan join analitik tingkat enterprise mendorong peralihan ke arsitektur MPP (Massively Parallel Processing) yang dapat menskalakan komputasi secara horizontal.

Mengapa PostHog beralih dari ClickHouse ke DuckDB?

ClickHouse tetap menjadi mesin analitik produk inti PostHog, tetapi kurang sesuai untuk menjalankan pemodelan pelanggan yang berat pada klaster bersama. Beban dbt yang berlangsung lama memicu konflik sumber daya, optimasi join eksternal terbatas, dan kompatibilitas alat data tidak memadai. Pada 22 Juni 2026, PostHog memilih DuckDB khusus per tenant, DuckLake di atas S3, serta ekstensi DuckHog untuk eksplorasi lokal.

ClickHouse tetap menjadi fondasi analitik produk inti PostHog dan memproses miliaran peristiwa telemetri pengguna setiap hari. Namun, ketika digunakan sebagai Managed Warehouse untuk pelanggan—tempat pipeline data menggabungkan data bisnis eksternal seperti tagihan Stripe, objek CRM, dan replika PostgreSQL produksi dengan aliran peristiwa mentah—muncul tiga hambatan arsitektur:

Konflik multi-tenant: Klaster ClickHouse bersama PostHog dioptimalkan untuk kueri web berlatensi rendah yang selesai dalam milidetik. Sebaliknya, transformasi dbt yang kompleks dapat berlangsung berjam-jam. Kueri pemodelan berat pada klaster non-elastis memicu noisy-neighbor, perebutan thread, dan restart node tak terduga yang mengancam SLA aplikasi inti.
Kesenjangan optimasi kueri: ClickHouse sangat cepat jika kueri disesuaikan dengan mesin tabel dan kunci indeks primernya. Namun, ClickHouse tidak memiliki optimizer kueri berbasis biaya (CBO) serbaguna dan matang untuk menyusun ulang join SQL deklaratif yang kompleks pada skema eksternal tanpa indeks. Integrasi dengan format penyimpanan objek cloud seperti Delta Lake dan Apache Iceberg juga belum cukup matang; peningkatan versi minor kadang menghasilkan variasi rencana kueri yang tidak deterministik.
Kompatibilitas perkakas data: Alur kerja rekayasa data modern mengandalkan perkakas SQL standar dan kerangka transformasi seperti dbt. Koneksi langsung ke klaster ClickHouse bersama tidak aman karena dapat mengganggu seluruh klaster, sementara abstraksi eksklusif PostHog, HogQL, belum didukung secara luas oleh driver BI standar dan antarmuka klien SQL.

Untuk mengatasi tantangan isolasi dan kompatibilitas tersebut, PostHog mengumumkan migrasi awal ke DuckDB pada 22 Juni 2026. Rancangannya mengisolasi beban komputasi untuk setiap tenant:

Komputasi khusus per tenant: Setiap organisasi memperoleh worker eksekusi DuckDB khusus dan terisolasi, sehingga menghilangkan perebutan sumber daya antar-tenant.
Eksekusi vektorisasi dalam proses: Mesin eksekusi vektorisasi DuckDB memberikan pemrosesan analitik satu node yang cepat untuk format kolom vektorisasi seperti Apache Parquet.
Penyimpanan terpisah melalui DuckLake: Dengan memasang katalog DuckLake di atas penyimpanan objek Amazon S3, komputasi dapat dijalankan sesuai permintaan sementara data mentah tetap berada di penyimpanan objek.
Offload beban kerja lokal melalui DuckHog: PostHog mengembangkan DuckHog, ekstensi DuckDB khusus yang memungkinkan instans lokal pengguna dan agen AI mengueri subset data warehouse langsung dari penyimpanan objek, tanpa perjalanan bolak-balik ke klaster yang tidak perlu.

Bagaimana arsitektur Duckgres menghubungkan PostgreSQL dan DuckDB?

Duckgres menyediakan kompatibilitas PostgreSQL di depan worker DuckDB yang terisolasi, sehingga klien seperti psql, dbt, dan alat BI dapat terhubung melalui pgwire. Control plane meneruskan eksekusi melalui Arrow Flight SQL, menerjemahkan sintaks PostgreSQL, dan memvalidasi fallback untuk sintaks asli DuckDB. Pool worker hot-idle mengurangi waktu cold-start, sementara DuckLake memisahkan komputasi dari data Parquet di S3.

PostHog merancang Duckgres, lapisan antarmuka dan orkestrasi sumber terbuka di PostHog/duckgres, agar worker DuckDB satu node berfungsi sebagai data warehouse cloud terpadu.

Dalam mode control plane, Duckgres memisahkan handler protokol PostgreSQL di sisi depan dari worker eksekusi di sisi belakang dengan Arrow Flight SQL melalui Unix Socket / gRPC. Pelacakan eksekusi kueri menggunakan pengenal query_id UUIDv7 yang berurutan berdasarkan waktu. Pengenal ini disematkan langsung pada span OpenTelemetry (duckgres.query_id) untuk menghubungkan panggilan RPC, peristiwa kesalahan, dan log kinerja worker.

  +------------------------------------------------------------------+
  |                       Klien PostgreSQL                           |
  |             (psql, dbt, alat BI, agen MCP)                       |
  +------------------------------------------------------------------+
                                   |
                                   | TLS / pgwire (Port 5432)
                                   v
  +------------------------------------------------------------------+
  |                 Ingress Control Plane Duckgres                   |
  |             (Terminasi TLS & Autentikasi Cleartext)               |
  +------------------------------------------------------------------+
                                   |
              +--------------------+--------------------+
              |                                         |
              v                                         v
  +-----------------------+                 +-----------------------+
  | Transpiler Tingkat 1  |                 | Fallback Tingkat 2    |
  | (pg_query_go /        |  Gagal Parse    | (Validasi EXPLAIN     |
  |  libpg_query)         |---------------->|  untuk DuckDB Native) |
  +-----------------------+                 +-----------------------+
              |                                         |
              +--------------------+--------------------+
                                   |
                                   | Arrow Flight SQL (gRPC / UDS)
                                   v
  +------------------------------------------------------------------+
  |                     Pool Worker Hot-Idle                         |
  |           (Instans DuckDB terisolasi dan dipanaskan)             |
  +------------------------------------------------------------------+
                                   |
                                   | S3 / Penyimpanan Objek
                                   v
  +------------------------------------------------------------------+
  |                   Katalog dan Penyimpanan DuckLake               |
  +------------------------------------------------------------------+

Komponen fungsional inti arsitektur proxy Duckgres dipetakan langsung ke subsistem database standar:

⚙️ Komponen & Fungsi Arsitektur

🔌 Protokol Wire PostgreSQL (pgwire / Duckgres)
Mendengarkan pada port 5432 dengan autentikasi kata sandi cleartext melalui TLS, sehingga klien SQL standar (psql, DBeaver, alat BI, dbt) dapat terhubung secara native.
🧠 Pemrosesan Kueri Dua Tingkat
- Tingkat 1: Inspeksi pohon parse melalui pg_query_go (pembungkus libpg_query) menerjemahkan sintaks PostgreSQL dan katalog sistem menjadi SQL DuckDB.
- Tingkat 2: Mekanisme fallback meneruskan konstruksi native DuckDB (QUALIFY, SUMMARIZE, COLUMNS) melalui pemeriksaan validasi EXPLAIN agar dapat dieksekusi langsung.
📂 Pemasangan Katalog DuckLake
Menjalankan pemasangan katalog secara otomatis saat worker dimulai melalui penyimpanan metadata PostgreSQL, sehingga komputasi terpisah dari penyimpanan objek S3 berbasis Parquet.
🚀 Pool Worker Hot-Idle
Layanan control plane Kubernetes yang menyiapkan dan memarkir pod worker yang menganggur (hot_idle) untuk menghilangkan latensi inisialisasi kontainer saat cold-start.
Catatan: Pada 8 Oktober 2026, PostHog secara resmi menghentikan pengelolaan duckgres dan menggantinya dengan control plane internal bernama hogtower. Namun, mesin protokol pgwire dan logika eksekusi kueri DuckDB yang mendasarinya tetap melayani lalu lintas pengguna aktif selama masa transisi.

Mengapa DuckDB dan DuckLake mencapai batas skala?

DuckDB dan DuckLake memudahkan analisis satu node, tetapi beban internal PostHog yang melampaui 2 PB, 1 triliun baris, dan 15,3 juta snapshot mengungkap batas kapasitas. Kapasitas worker sulit diperkirakan, metadata katalog dan commit menjadi mahal, koneksi pgwire menambah beban operasional, dan patch fork pribadi menambah tanggungan pemeliharaan. Kombinasi batas ini mendorong PostHog mencari pemrosesan terdistribusi.

Pengujian arsitektur ini pada dataset internal PostHog mengungkap sejumlah kegagalan sistem kritis.

1. The Single-Node Cloud Sizing Dilemma

DuckDB adalah mesin dalam proses yang berjalan pada satu node. Karena node worker komputasi di lingkungan Kubernetes harus disediakan sebelum kueri tiba, kebutuhan CPU dan memori untuk join deklaratif yang arbitrer sulit diprediksi.

Pod worker dengan kapasitas terlalu kecil mencapai batas memori per sesi DuckDB dan memicu spill ke disk, sehingga kinerja kueri turun drastis. Sebaliknya, worker yang kapasitasnya berlebihan membuat biaya infrastruktur cloud membengkak.

Selain itu, model threading default DuckDB (2.5 × runtime.NumCPU()) dan pengelolaan memori per sesi membuat jejak memori tidak stabil ketika beban multi-tenant ditempatkan bersama atau lonjakan kueri terjadi secara bersamaan. Versi awal mesin juga belum memiliki prefetch data S3 asinkron, sehingga latensi penyimpanan objek menjadi hambatan eksekusi yang besar.

2. DuckLake Metadata & Commit Latency

Katalog metadata DuckLake dirancang untuk mempertahankan skema portabel lintas database dan berbagai mesin SQL. Namun, rancangan ini menghalangi penggunaan pengindeksan atau optimasi skema yang spesifik untuk mesin tertentu. Akibatnya, setiap commit penulisan satu tabel memicu pembacaan ulang statistik seluruh katalog, termasuk statistik historis tabel yang sudah lama dihapus dan mencakup lebih dari 99% baris statistik katalog.

Pembersihan metadata manual untuk sementara mempercepat commit 30–50 kali lipat, tetapi statistik yang membengkak cepat terakumulasi kembali jika tidak dibersihkan.

Selain itu, beban operasional koneksi proxy metadata native—yang membuka port dan endpoint koneksi untuk inspeksi katalog langsung—menyebabkan kehabisan koneksi pada instans PostgreSQL yang mendasarinya (AWS Aurora/RDS).

3. PostgreSQL Wire Protocol Overhead

Meniru PostgreSQL melalui TCP (pgwire) menambah tekanan operasional berkelanjutan dibandingkan API HTTP stateless. Pengelolaan koneksi TCP stateful berumur panjang, pool koneksi klien, dan batas waktu sesi idle menimbulkan kegagalan berulang pada skala besar.

Infrastruktur cloud juga menyediakan mekanisme load balancing yang kurang fleksibel untuk koneksi TCP/pgwire mentah dibandingkan HTTP Application Load Balancer (AWS NLB vs. ALB).

Selain itu, variasi perilaku driver klien yang terus bertambah—misalnya pemeriksaan status parameter khusus driver dan variasi kueri katalog sistem—memaksa lapisan proxy untuk terus menambahkan patch khusus.

4. Fork Maintenance Burden

Untuk mengatasi hambatan kinerja dan kemacetan commit metadata pada skala petabita, PostHog harus memelihara patch internal khusus dalam fork DuckLake privat. Mempertahankan fork terpisah menghapus manfaat utama infrastruktur sumber terbuka: pengembangan upstream oleh komunitas, perbaikan bug bersama, dan pemeliharaan ekosistem.

Mengapa PostHog beralih ke Trino dan HogLake?

Pada 2 November 2026, PostHog mengumumkan perpindahan Managed Warehouse dari DuckDB menuju Trino dan format tabel terbuka proprieternya, HogLake. Trino membagi kueri secara paralel ke banyak worker dan menskalakan komputasi secara horizontal untuk join multi-terabita. ClickHouse tetap menangani analitik event produk inti, sedangkan Trino dan HogLake diarahkan untuk pemodelan data eksternal multi-sumber.

Architectural Comparison: Single-Node vs. Distributed Engines

Mesin satu node (DuckDB):
Kekuatan: Operasional sederhana tanpa konfigurasi, waktu mulai nyaris nol, eksekusi tertanam, dan pengalaman pengembang lokal yang unggul.
Batas: Batas memori tetap, hambatan I/O satu node, kebutuhan menentukan kapasitas worker secara manual, dan tidak adanya skala elastis horizontal.
Mesin terdistribusi (Trino):
Kekuatan: Perencanaan kueri terdistribusi MPP tahap demi tahap, elastisitas horizontal di banyak node worker, perutean HTTP stateless, serta tahap kueri terisolasi yang dapat menangani join deklaratif multi-terabita pada penyimpanan objek.
Batas: Kompleksitas operasional lebih tinggi, overhead orkestrasi klaster, dan latensi inisialisasi kueri yang tidak nol.

Selama migrasi ini, control plane menggunakan penempatan cell Trino eksplisit (registered:<cell-id>) dan rute validasi kredensial layanan (POST /auth/trino/service-credentials). Rancangan ini memungkinkan coordinator Trino mengautentikasi koneksi tenant secara dinamis menggunakan kredensial layanan yang sudah ada, sehingga menjamin penghubung protokol bagi klien lama tanpa downtime selama transisi platform.

Apa pelajaran utama bagi data engineer?

Pengalaman PostHog menunjukkan bahwa pilihan mesin analitik harus mengikuti bentuk beban kerja, bukan dogma teknologi. DuckDB cocok untuk analisis lokal, alur kerja agent tertanam, dan data yang muat pada satu node; Trino lebih sesuai untuk join skala besar yang memerlukan paralelisme dan elastisitas. Katalog metadata dan protokol koneksi juga perlu dinilai sebagai bagian inti arsitektur, bukan sekadar detail implementasi.

Perjalanan PostHog dari ClickHouse ke DuckDB lalu Trino memperlihatkan kompromi dalam penskalaan sistem analitik.

The Data Engineer's Architectural Playbook

Sesuaikan kapasitas dengan keunggulan mesin: Selaraskan pilihan database dengan skala data dan model eksekusi. Mesin satu node seperti DuckDB unggul untuk analisis lokal, alur kerja agent tertanam, dan dataset yang muat dalam memori node. Ketika beban analitik melampaui miliaran baris, mesin MPP terdistribusi horizontal seperti Trino menjadi kebutuhan.
Hindari emulasi protokol wire yang tidak perlu: Meniru protokol wire TCP stateful (pgwire) menambah biaya pemeliharaan kasus tepi, keunikan kompatibilitas driver, dan batasan load balancing. Platform data cloud-native modern sebaiknya memilih antarmuka HTTP atau gRPC stateless jika memungkinkan.
Utamakan katalog metadata yang teruji: Pengelolaan metadata katalog sering menjadi hambatan tersembunyi data lake analitik. Format katalog perlu mendukung commit inkremental yang ringan, pemangkasan partisi, dan vacuum latar belakang otomatis agar pembacaan ulang katalog tidak memperburuk latensi kueri saat tabel bertambah besar.

Join the Design Partner Program

Apakah Anda mengelola data warehouse multi-terabita, kesulitan menskalakan join analitik, atau menghadapi biaya warehouse tinggi? PostHog aktif bekerja sama dengan tim data untuk menguji dan menyempurnakan mesin Trino + HogLake generasi berikutnya. Hubungi tim engineering melalui benjamin.k@posthog.com untuk menyampaikan umpan balik atau membahas peluang kemitraan desain dengan akses awal.

Posthog beralih dari clickhouse ke duckdb dan berenti di trino.