PostHog Tinggalkan DuckDB: 2 PB, 1 Triliun Baris, dan Batas Mesin Tunggal

PostHog memindahkan warehouse mereka keluar dari DuckDB setelah menampung sekitar 2 petabyte data, kira-kira 1 triliun baris, dan 15,3 juta snapshot. Perpindahan itu diputuskan setelah satu penulisan ke satu tabel bisa memakan lebih dari tiga menit, dan mereka menghabiskan tiga bulan terakhir merancang ulang tanpa DuckDB. Arah barunya: Trino versi mereka sendiri dengan format tabel open source bernama HogLake. Tim menuliskan alasannya terbuka di blog engineering PostHog pada 2 November 2026, dan mereka tetap menyebut DuckDB sebagai alat single-node terbaik.

TL;DR

• Warehouse PostHog sempat menampung sekitar 2 PB, 1 triliun baris, dan 15,3 juta snapshot sebelum pindah.
• Pemicunya bukan mesin query-nya, tapi katalog DuckLake: satu penulisan tabel bisa lewat tiga menit.
• Lebih dari 99 persen baris statistik katalog milik tabel yang sudah tidak ada; pembersihan membuat tulis 30 sampai 50 kali lebih cepat, tapi barisnya tumbuh lagi.
• DuckDB dipilih lima bulan sebelumnya karena klaster ClickHouse bersama tidak sanggup menangani query modeling berjam-jam dan tidak punya optimizer berbasis biaya.
• Penggantinya Trino plus format tabel sendiri, HogLake, diuji di skala petabyte sebelum diserahkan ke design partner.

Kenapa DuckDB ditinggalkan padahal awalnya dipilih?

Karena masalahnya bergeser dari "query terlalu lambat" menjadi "beban tidak bisa diprediksi". DuckDB awalnya masuk untuk menggantikan klaster ClickHouse bersama yang tidak sanggup menangani query modeling berjam-jam dan tidak memiliki optimizer berbasis biaya. Dengan DuckDB, setiap pelanggan mendapat instance sendiri, dan alat seperti dbt bisa terhubung lewat protokol Postgres.

Lima bulan kemudian, pelanggan menjalankan query yang jauh lebih kompleks daripada perkiraan. Untuk menjalankannya dengan aman, PostHog harus menentukan ukuran worker sebelum query datang. Di sinilah masalahnya: memperkirakan kebutuhan CPU dan memori untuk satu query tertentu sulit, dan pelanggan tidak seharusnya diminta menebak. Menambah disk adalah opsi, tapi query jadi terlalu lambat dan terlalu mahal untuk dipertahankan.

PostHog juga menyebut dua gesekan teknis lain. Pengambilan data dalam jumlah besar dari S3 berjalan tanpa async fetching, kemampuan yang baru ditambahkan DuckDB belakangan. Dan prediktabilitas, yang jadi keunggulan DuckDB di laptop, justru berubah jadi beban ketika mesinnya dipakai banyak pelanggan dengan pola pemakaian yang tidak seragam.

Berapa besar data yang harus dipindahkan?

Angka yang disebut cukup konkret: sekitar 2 PB, kira-kira 1 triliun baris, dan 15,3 juta snapshot. PostHog sengaja memakai produknya sendiri sebagai pelanggan pertama, jadi seluruh data perusahaan masuk ke DuckLake sebelum mereka memutuskan keluar.

Yang menarik, masalah terbesarnya bukan volume baris saat query. Volume itu bisa ditangani mesin kolumnar mana pun dengan cukup memori. Yang jadi penghambat adalah metadata: katalog yang harus tetap portabel, statistik yang harus dibaca ulang, dan koneksi ke database metadata yang jumlahnya membengkak.

Metrik	Angka yang disebut	Konteks
Total data	Sekitar 2 PB	Saat mulai memindahkan beban
Jumlah baris	Sekitar 1 triliun	Seluruh produk PostHog
Snapshot	15,3 juta	Objek di format lakehouse
Waktu tulis satu tabel	Lebih dari 3 menit	Karena commit membaca ulang statistik katalog
Percepatan setelah bersih-bersih	30 sampai 50 kali	Setelah baris statistik mati dibuang
Baris statistik usang	Lebih dari 99 persen	Milik tabel yang sudah tidak ada

Apa masalah sebenarnya: mesinnya atau katalognya?

Sebagian besar bukti di posting itu menunjuk ke katalog. DuckLake, format lakehouse dari pembuat DuckDB, dirancang agar kompatibel dengan banyak database SQL. Konsekuensinya, skema katalognya harus tetap portabel, dan itu membatasi optimasi yang bisa dipakai satu mesin tertentu.

Efek paling mahal muncul saat menulis. Setiap commit membaca ulang statistik untuk seluruh katalog, sehingga satu penulisan ke satu tabel bisa melewati tiga menit. PostHog mencoba tuning dengan indeks tabel dan penyesuaian lain, tapi tetap harus kompatibel penuh dengan skema resmi, jadi ruang manuver-nya sempit.

Temuan lain lebih mengejutkan: lebih dari 99 persen baris statistik di katalog milik tabel yang sudah tidak ada. Membersihkannya membuat penulisan 30 sampai 50 kali lebih cepat, tapi baris itu tumbuh kembali. Artinya pembersihan manual bukan solusi, hanya penunda. Menambah jumlah koneksi ke database metadata juga bukan jalan keluar, karena setiap koneksi punya biaya nyata di Postgres yang dipakai bersama.

Dokumentasi DuckDB dan DuckLake menjelaskan desain ini sebagai kelebihan portabilitas. PostHog tidak menyangkalnya; mereka hanya menyimpulkan bahwa portabilitas lintas katalog bukan prioritas di skala mereka.

Kenapa protokol Postgres juga ditinggalkan?

Karena melayani koneksi Postgres jauh lebih sulit diskalakan daripada HTTP. Menawarkan koneksi langsung ke port 5432 terdengar sederhana, tapi pada praktiknya PostHog harus mengurus reconnect yang hilang, TTL, koneksi idle, dan koneksi berumur panjang yang mahal.

Tooling untuk load balancing pgwire juga jauh lebih sedikit dibanding HTTP. PostHog membandingkannya dengan selisih kemudahan antara Network Load Balancer dan Application Load Balancer di AWS: yang pertama bekerja di lapisan koneksi dan tidak punya konsep header, sehingga routing di Kubernetes jadi jauh lebih kaku.

Ada pula biaya dukungan. Klien Postgres jumlahnya sangat banyak, dan masing-masing punya ekspektasi perilaku sendiri. Pelanggan terus meminta perbaikan pada klien atau library mereka, dan meski banyak permintaan itu dituruti, cakupannya tidak pernah cukup. Bagi tim kecil, ini pelajaran penting: protokol yang sudah dikenal luas bukan berarti murah untuk dilayani.

Bagaimana bentuk penggantinya?

PostHog membangun ulang warehouse di sekitar Trino versi mereka sendiri, dengan format tabel open source baru bernama HogLake. Mereka menyatakan sedang mengujinya di skala petabyte milik PostHog sendiri sebelum menyerahkannya ke design partner.

Trino dipilih sebagai mesin query terdistribusi yang sejak awal dirancang untuk memisahkan komputasi dari penyimpanan, dan dokumentasinya terbuka di Trino Docs. Dengan format tabel sendiri, PostHog bisa memutuskan sendiri aturan statistik dan katalog tanpa terikat kompatibilitas penuh ke implementasi lain.

Ada catatan kejujuran di akhir posting: mereka mengaku sudah belajar untuk tidak terlalu mempromosikan teknologi di balik warehouse. Yang dinilai pelanggan adalah pengalaman memakainya, bukan nama mesinnya. Pernyataan itu masuk akal dari tim yang baru saja menghabiskan lima bulan membangun di atas satu mesin, lalu tiga bulan berikutnya membongkarnya.

Kapan mesin single-node masih pilihan tepat?

Selama beban kerjanya bisa diprediksi dan muat dalam satu mesin. DuckDB unggul justru pada hal-hal yang disebut PostHog: tahan banting, hampir selalu menyelesaikan query, dan melimpah ke disk ketika kehabisan memori. Untuk analisis di laptop, pipeline data kecil, atau alat internal dengan satu pengguna, kombinasi itu sulit dikalahkan.

Batasnya muncul ketika dua kondisi bertemu: query tidak bisa diprediksi ukurannya, dan mesin dipakai banyak pihak sekaligus. Di titik itu, menjamin keadilan antar pengguna menjadi pekerjaan tersendiri, dan mesin single-node tidak menyediakan alat untuk itu.

Kriteria	DuckDB single-node	Trino terdistribusi
Beban kerja	Terukur, satu pengguna atau satu tim	Bervariasi, banyak pelanggan
Kebutuhan memori	Harus muat atau melimpah ke disk	Dibagi antar worker
Kerumitan operasional	Rendah, satu proses	Tinggi, banyak komponen
Keadilan antar pengguna	Tidak jadi prioritas	Perlu dirancang sejak awal
Cocok untuk	Analisis lokal, data kecil sampai menengah	Warehouse layanan berbayar

Apa yang bisa dipelajari tim yang memilih warehouse?

Pelajaran pertama, ukur katalognya, bukan cuma tabelnya. Pada kasus PostHog, waktu tulis dihabiskan untuk membaca statistik metadata, bukan untuk menulis data. Tim yang menguji warehouse hanya dengan query SELECT akan melewatkan masalah ini sepenuhnya.

Pelajaran kedua, uji dengan beban yang tidak sopan. Query modeling berjam-jam adalah yang membuat ClickHouse bersama gagal, dan query kompleks pelanggan adalah yang membuat DuckDB kewalahan. Benchmark dengan query rapi dari dokumentasi tidak akan menemukan batas itu.

Pelajaran ketiga, hitung biaya protokol kompatibilitas. Menyedot pelanggan dengan janji "cukup sambungkan klien Postgres Anda" berarti berkomitmen meniru perilaku banyak klien yang berbeda. Kalau tim tidak siap menanggungnya, jalur HTTP lebih murah sejak awal.

Pelajaran keempat, sisakan ruang untuk mundur. PostHog bisa pindah dalam tiga bulan karena mereka mengendalikan pipeline-nya sendiri dan menyimpan data dalam format terbuka di object storage. Tim yang menyimpan state di dalam mesin tunggal tidak punya kemewahan itu: memindahkan warehouse berarti memindahkan semuanya sekaligus.

Bagaimana cara menguji apakah warehouse sudah mendekati batas?

Mulai dari pertanyaan yang tidak nyaman: berapa lama satu penulisan ke satu tabel ketika katalog sudah besar. Kalau angka itu naik seiring bertambahnya jumlah tabel, bukan seiring bertambahnya baris, berarti yang menjadi hambatan adalah metadata, dan menambah memori tidak akan menolong.

Uji kedua adalah prediktabilitas. Catat kebutuhan memori puncak untuk seratus query terakhir, lalu lihat sebarannya. Kalau rentangnya melebar cepat sementara jumlah pengguna tetap, tim akan segera kesulitan menentukan ukuran worker, dan fase berikutnya biasanya berupa keluhan pelanggan tentang query yang tiba-tiba gagal.

Uji ketiga adalah keadilan. Jalankan satu query berat bersamaan dengan sepuluh query ringan, lalu ukur dampaknya ke yang ringan. Pada sistem single-node, query berat akan menyerap hampir semua sumber daya, dan tidak ada mekanisme yang membatasi kecuali kuota buatan sendiri.

Uji keempat adalah biaya keluar. Hitung berapa lama waktu yang dibutuhkan untuk memindahkan seluruh data ke mesin lain, dengan asumsi data sudah ada di object storage dalam format terbuka. Kalau jawabannya berminggu-minggu atau tidak mungkin, keputusan memilih warehouse itu perlu ditimbang ulang sebelum volumenya bertambah.

FAQ

Apakah PostHog berhenti memakai DuckDB sama sekali?

Untuk warehouse mereka, ya. Namun posting itu menyatakan tim tetap menyukai DuckDB dan menganggapnya alat single-node terbaik untuk menganalisis data dalam jumlah besar.

Berapa lama proses perpindahannya?

Mereka menyebut tiga bulan terakhir dipakai untuk merancang ulang tanpa DuckDB, setelah lima bulan sebelumnya membangun warehouse di atas DuckDB.

Apa itu HogLake?

Format tabel open source buatan PostHog yang dipakai bersama Trino versi mereka. Format ini masih diuji di skala petabyte internal sebelum diserahkan ke design partner.

Kenapa penulisan tabel bisa lewat tiga menit?

Karena setiap commit membaca ulang statistik untuk seluruh katalog DuckLake. Statistik itu juga menumpuk: lebih dari 99 persen barisnya milik tabel yang sudah tidak ada.

Apakah ClickHouse dipertimbangkan lagi?

Tidak disebut sebagai kandidat baru. Alasan meninggalkan ClickHouse sebelumnya adalah ketidakmampuan klaster bersama menangani query modeling berjam-jam dan tidak adanya optimizer berbasis biaya.