HogLake

HogLake is a petabyte-scale open table format and lakehouse catalog service from product-analytics company PostHog, made public on November 2, 2026 with the post Why we're moving our warehouse off DuckDB; the code is open source at PostHog/hoglake on GitHub.

Five months earlier PostHog had rebuilt its managed warehouse on DuckDB plus DuckLake, but at roughly 2 PB, 1 trillion rows and 15.3 million snapshots, single-table writes could take over three minutes and catalog statistics kept piling up. PostHog switched to its own Trino fork plus HogLake, and new Trino clients now use HogLake automatically.

Design highlights

• Catalog as a service: all catalog SQL lives server-side behind a REST API; clients never see the metadata database.
• Postgres as the only metadata backend: snapshots, schema evolution, data files and statistics are rows in Postgres, while data lives as Parquet in object storage.
• Commits scoped to the write set: one commit is one snapshot, and its cost does not grow with catalog size.
• Deletion vectors for row-level deletes, one live vector per data file.
• Server-owned maintenance: compaction, snapshot expiry and cleanup run as background jobs.
• Time travel, a changefeed with consumer offsets, Prometheus metrics and an audit log.

Compared with DuckLake and Iceberg

	HogLake	DuckLake	Iceberg
Metadata lives in	Postgres, behind a service	An RDBMS read directly by clients	Files in object storage plus a catalog pointer
Who commits	The server	Every client (embedded extension)	Every client (pointer swap)
Engine support	Trino connector, DuckDB extension, Python; Iceberg REST facade designed	DuckDB	Nearly universal

Components

A Kotlin/Ktor server, the pyhoglake Python client, a DuckDB extension, a React web console and the hedgerow replication daemon.

When it fits

• Lakehouse teams at TB-to-PB scale where DuckLake's single-node or catalog performance is a bottleneck.
• Architectures that want metadata centralized in Postgres, with one service committing and maintaining it, instead of many clients racing.
• Setups using Trino for distributed queries that still want DuckDB read/write access locally.

Getting started

1. Read PostHog's post at posthog.com/blog/moving-off-duckdb for why they migrated.
2. Clone PostHog/hoglake on GitHub and deploy Postgres plus the HogLake server.
3. Read and write Parquet tables through the Trino connector, the DuckDB extension or pyhoglake.
4. PostHog Cloud users: newly provisioned warehouses (Trino clients) use HogLake automatically, and existing DuckLake catalogs remain supported.