文章把长期痛点归纳为三类：从 Postgres 事务到 ClickHouse 可查询，中间要经过复制槽、连接器、消息队列、写入端与去重逻辑，任何一环的延迟都会让“实时”仪表盘失真；智能体类工作负载对数据新鲜度更敏感，用二十分钟前的聚合结果做决策等于以机器速度犯错；权限与脱敏规则在两套系统中各写一遍，随时间漂移。

整合方向分三层。共享层上，Postgres、WarehousePG 与 ClickHouse 已能通过 Apache Iceberg 读写同一批表并互相查询，双方计划进一步做统一 catalog 与统一治理模型；智能体层上，目标是策略在数据所在处定义一次、由各引擎执行；运维层上，Altinity 的 Kubernetes Operator（拉取量超过 1 亿）与 EnterpriseDB 创建并捐赠给 CNCF 的 CloudNativePG 由同一体系支持，覆盖自带云、自建 Kubernetes 或 OpenShift、隔离网络与全托管等部署选择。文章同时提醒，这些属于规划而非当下可下载的成品。

对企业 IT 与数据平台的意义在于选型判断：交易与分析双引擎的运维与审计成本长期被低估，统一治理若落地会显著减少自建数据管道的维护量。但合并路线由单一厂商主导，需关注开放性与许可条款，建议先以 Iceberg 共享表作为最小可行验证点。

来源：The New Stack，原文。