PostHog Drops DuckDB for Its Own Trino and HogLake After a DuckLake Catalog Hit 15.3 Million Snapshots

PostHog is rebuilding its data warehouse without DuckDB, four months after announcing one built on it. Benjamin Knofe-Vider's Nov. 2 post, "Why we're moving our warehouse off DuckDB", says the catalog layer broke first: at about 2 petabytes and roughly 1 trillion rows, a single-table write could take more than three minutes.

The post does not name a customer count, an incident date or a cutover date. It gives one set of scale figures, one pair of before-and-after numbers, and a destination: "our own flavor of Trino" and "our own open table format," HogLake, which PostHog says it is testing at petabyte scale before offering it to design partners. No timeline is given.

What PostHog promised on June 29

Eric Duong's launch post, dated June 29, 2026, described "fully single-tenant DuckDB instances" for each organisation, sleeping when idle and waking on a query. DuckDB is an analytics database built to run on one machine. The design put the data in S3 behind a DuckLake catalog, so that PostHog would not be locked into DuckDB, and offered a Postgres wire endpoint so that psql and BI tools could connect. The launch post gave no pricing and no benchmarks, and sent readers to a waitlist for the beta.

Knofe-Vider's post says the rebuild happened about five months earlier. That is longer than the four months between the two posts, so the work evidently began before the announcement.

The numbers behind the exit

Figure	Value in PostHog's post
Data held when it left DuckLake	About 2 PB
Rows	Roughly 1 trillion
Catalog snapshots	15.3 million
Slowest single-table write	More than 3 minutes
Share of statistics rows belonging to deleted tables	Over 99%
Write speedup after cleaning those rows	30 to 50 times
Time spent re-architecting without DuckDB	3 months

The 99 percent figure is the one only a reader of the post would catch. Each commit re-read statistics for the entire catalog, and more than 99 percent of those rows belonged to tables that no longer existed. Deleting them made writes 30 to 50 times faster, "but the rows kept returning," in the post's account of why cleanup was no fix.

Why DuckLake's design shows up here

DuckLake, announced May 27, 2025 by Mark Raasveldt and Hannes Muhleisen, keeps table data as Parquet files on blob storage and moves "all metadata structures into a SQL database." Its catalog can sit in Postgres, SQLite, MySQL, MotherDuck or a local DuckDB file, and the announcement called the extension experimental when it shipped with DuckDB 1.3.0.

Knofe-Vider's post says that portability was a cost: the catalog schema had to stay portable across SQL databases, which limited optimisations. Connection counts also strained shared Postgres instances, and direct connections on port 5432 were harder to scale than HTTP, with reconnects, connection lifetimes and inconsistent client behaviour listed as problems.

The worker model was the second problem. In the cloud, each DuckDB worker had to be sized before a query arrived, and predicting CPU and memory for a query was hard. Fetching large amounts of S3 data was a bottleneck until DuckDB added async support; the post gives no release or date for that change.

PostHog also ended up carrying patches in a fork.

What this does and does not show

The post describes one company's workload at 2 PB. It is not a benchmark of DuckDB, and it does not say DuckDB was slow on a single machine; Knofe-Vider writes that it is strong there. The failure was a metadata catalog under many writers and an unpredictable per-query worker size.

For teams weighing a lakehouse format, the useful detail is the cause, not the verdict. A catalog that never prunes statistics for dropped tables, on shared Postgres, hit a write ceiling in PostHog's hands. For another infrastructure project whose own numbers came with caveats, see Lightpanda 1.0 and its Web Platform Tests score; for open-source developer tooling built around Git, see Worktrunk.

The next fixed point is PostHog's design-partner offer for HogLake. The post points interested readers to its author and sets no date.