單節點引擎在雲端多租戶環境的擴展困境
PostHog 團隊指出，DuckDB 作為單節點分析工具表現優異，具備高可靠性與記憶體溢出至磁碟的機制。然而，當應用於雲端服務時，這些特性反而成為瓶頸。
為了確保服務穩定性，系統必須在查詢到達前預先配置工作節點的資源規模。PostHog 發現難以準確預測特定查詢所需的 CPU 與記憶體資源，這使得向客戶說明所需資源變得困難。
此外，DuckDB 近期才加入非同步抓取 S3 資料的功能，此前在大量數據讀取上存在效能限制。團隊認為用戶不應需擔心底層資源配置，服務供應商應負責處理這些複雜性以提供可預測的體驗。
DuckLake 格式因相容性要求導致寫入效能低落
PostHog 曾預設安裝 DuckLake 擴充功能，這是 DuckDB 開發者推出的湖倉架構格式，旨在簡化設置並支援多種環境。但在 PostHog 的規模下，該格式並非為分散式擴展設計。
DuckLake 的目錄結構必須保持跨 SQL 資料庫的可攜性，這限制了引擎特定的最佳化選項。在 PostHog 的環境中，單表寫入操作可能耗時超過三分鐘，因為每次提交都需重新讀取整個目錄的統計數據。
團隊嘗試透過建立表格索引等方式進行調優，但為了維持與官方架構的百分之百相容性，最佳化空間受到嚴格限制。此外，目錄統計資料中超過 99% 的列屬於已不存在的表格，雖然清理這些資料能使寫入速度提升 30 至 50 倍，但這些無效數據會持續重新生成。
DuckLake 開啟大量連線至元資料資料庫的行為，在共享 Postgres 實例上造成顯著成本負擔。PostHog 最終選擇維護一個分支版本以快速修復問題，但這違背了使用開源社群生態的初衷。
PB 級數據規模下的實際運作挑戰
PostHog 將所有內部數據遷移至 DuckLake 以進行內部測試，當時數據量約為 2 PB，包含約 1 兆行資料與 1,530 萬個快照。
在如此規模下，系統出現多種難以在 DuckLake 架構範圍內修復的問題。團隊表示，他們原本希望貢獻於現有社群並促進其發展，但由於無法以所需速度合併變更，最終不得不自行維護補丁。
Postgres 協議連線管理的複雜性與工具鏈缺失
提供透過 Port 5432 的直接 Postgres 連線看似理想，但在擴展性上遠不如 HTTP 協議。處理斷線重連、TTL 管理以及大量閒置連線的維護難度極高，且長時間連線成本昂貴。
相比 HTTP，針對 pgwire 協議的負載平衡工具鏈極為匱乏。PostHog 指出 AWS NLB 與 ALB 在易用性上的差異，並強調 HTTP 標頭在 Kubernetes 路由靈活性上的優勢。
此外，Postgres 客戶端生態系龐雜，每個客戶端都期望特定的行為模式。團隊投入大量時間修復各種客戶端相容性問題，但覆蓋率始終無法達到理想狀態。PostHog 決定將資源轉向構建優質的資料倉儲核心，而非追逐 Postgres 相容性的長尾需求。
轉向 Trino 與自研 HogLake 的新架構
PostHog 宣布已圍繞其自訂版本的 Trino 重新構建系統，並開發了名為 HogLake 的自有開放表格格式。團隊強調，評估重點在於用戶體驗而非技術炒作。
新架構已在 PostHog 自身的 PB 級規模數據上完成測試與驗證，確保穩定性後才準備提供給設計夥伴使用。PostHog 表示正在尋找擁有大量查詢數據需求的設計夥伴進行合作。
