pgEdge 加入合并 OLTP 与 OLAP 存储的浪潮，以支持 AI

liuaustin32026年08月11日约 6 分钟

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 ）(1 2 3 4 5 6 7 8群已经爆满 9群为纯聊天群，默认不加入不得发广告，自己公众号文章链接等，发一次直接踢，默认加入8群，开10群PolarDB专业学习群115+)

这篇报道的核心信息是：PostgreSQL 周边生态正在快速演化，ColdFront 的冷可写层是差异化亮点，但整个行业对 Iceberg 和 DuckDB 的依赖也带来了集中风险。

pgEdge 的 ColdFront 可能会吸引那些希望降低存储成本，同时又不想牺牲应用兼容性或修改历史数据能力的企业。

多年来，企业一直维持着分别处理事务型（OLTP）和分析型（OLAP）数据的系统，即使这意味着要在它们之间来回搬运数据。然而，随着自主代理和 AI 应用的兴起——它们既需要即时访问数据，又会生成大量运营数据——维持这种分离系统的成本和复杂性被进一步放大。

行业的反应非常迅速，数据仓库和数据库厂商纷纷提出竞争性方案来打破这些数据孤岛。过去几周，Databricks 推出了 LTAP，EDB 引入了 converged analytics，而在去年年底，Snowflake 发布了 pg_lake。这些方案都提供了不同的蓝图，试图让事务、分析和 AI 工作负载更紧密结合。

如今，分布式 PostgreSQL 提供商 pgEdge 推出了 ColdFront 的测试版。这是一种 PostgreSQL 原生的冷热数据分层架构，能自动将旧数据迁移到 Apache Iceberg 对象存储，同时保持 PostgreSQL 作为应用唯一需要交互的数据库。

在 ColdFront 的架构中，“热”指新数据，“冷”指旧数据。

分析师指出，ColdFront 的独特之处在于保持 PostgreSQL 作为主要接口，而其他方案则在数据重心上有所不同。Databricks 的 LTAP 让应用连接到 Lakehouse，在那里进行分析和 AI；EDB 保持 PostgreSQL 作为事务源，同时通过 Iceberg 暴露数据给分析引擎；Snowflake 的 pg_lake 则直接把 PostgreSQL 数据写入 Iceberg，让 PostgreSQL 和 Snowflake 都能查询同一份数据。

相比之下，ColdFront 仅把 Iceberg 当作 PostgreSQL 背后的透明存储层，自动将旧数据移出数据库，但应用仍在同一张表和 SQL 上运行。

pgEdge 联合创始人 Phillip Merrick 表示，这样的结果是：近期数据的查询仍在 PostgreSQL 上执行，而旧数据的请求则由嵌入式分析引擎 DuckDB 透明处理，应用无需引入 ETL 流程、额外查询路径或修改。更重要的是，存储在 Iceberg 的旧数据也能通过 PostgreSQL 更新，这形成了所谓的“冷可写层”。

为什么冷可写存储重要这种冷可写层对企业尤其有吸引力，因为它能在数据驻留、主权、合规和 AI 时代的运营需求之间取得平衡，而竞争方案往往需要牺牲其中至少一项。

随着企业保留越来越多由 AI 应用生成的历史运营数据用于审计和合规，他们必须能够在低成本存储中修改或删除记录，以满足数据保护和隐私法律的要求。其他方案往往让这一过程复杂化。

ColdFront 简化了这些流程。分析师 Chaturvedi 指出：“在大多数分层系统里，冷数据是只读的，所以 GDPR 删除请求意味着恢复—删除—再归档，至少要半天。ColdFront 的架构允许你通过一条 SQL 语句直接 UPDATE 或 DELETE 已归档的行。”

其他架构则各有取舍：Databricks 要求企业采用专有 Lakehouse 作为中心；Snowflake 要求应用区分 PostgreSQL 与分析表；EDB 则需要先把归档数据回迁到 PostgreSQL 才能修改。

这些取舍对金融、医疗、政府等受监管行业尤为重要，因为它们既要保持数据在客户控制的基础设施上，又要能修改历史记录以满足不断变化的合规要求。

DuckDB 的依赖尽管架构不同，所有厂商都在另一层出现了趋同：对 DuckDB 的依赖。

Ikonnikov 指出：“ColdFront 用 DuckDB 查询 Iceberg 数据；Snowflake 的 pg_lake 通过 pgduck_server 路由 Iceberg 查询；Databricks 的 Lakebase 也在部分分析处理中依赖 DuckDB。结果是，DuckDB 正迅速成为这一代 PostgreSQL-Iceberg 架构的事实标准嵌入式分析引擎。”

这种依赖带来集中风险：如果 DuckDB 出现许可变更、安全漏洞、性能瓶颈或治理问题，影响会同时波及多个产品。

因此，CIO 需要了解这些共享组件的成熟度和路线图。

不过，这种共享组件的相似性并不会让 CIO 更容易评估这些架构。

Moor Insights & Strategy 的分析师 Michael Leone 表示，大多数企业已经有既定的数据架构，CIO 应该基于现有数据、开发者和运营工作流来评估平台，而不是假设某个架构适合所有环境。

对于仍在制定长期数据战略的企业，Leone 建议先标准化 Iceberg，因为所有四种架构都支持这一开放表格式。这样企业未来可以灵活替换前端数据库或分析平台，而无需迁移底层数据。

不过 Ikonnikov 警告，这种可移植性也有限：“问题在于 Iceberg catalog 的治理。四种方案都写入 Iceberg，但使用不同的 catalog，它们之间的互操作性仍是未解难题。当不同系统的代理需要查询同一 Iceberg 表时，catalog 联邦会成为真正的运营挑战。”

架构	核心定位	应用兼容性	冷数据处理	适用场景
pgEdge ColdFront	PostgreSQL 单入口	应用无需改写 SQL	冷数据可写（UPDATE/DELETE），DuckDB 查询	强监管行业（金融、医疗、政府），需修改历史数据
Databricks LTAP	Lakehouse 中心	应用需连接 Lakehouse，部分改造	冷数据只读，需恢复再修改	AI/分析驱动企业，已有 Databricks 生态
EDB Converged Analytics	PostgreSQL 事务源 + Iceberg 分析	PostgreSQL 保持事务，分析需额外路径	冷数据需回迁 PostgreSQL 才能修改	PostgreSQL 已是核心系统，需扩展分析能力
Snowflake pg_lake	PostgreSQL + Snowflake 双入口	应用需区分 PostgreSQL 与 Snowflake 表	冷数据只读，需区分查询路径	已有 Snowflake 投入，需与 PostgreSQL 打通