pgEdge推出ColdFront，加入OLTP与OLAP融合赛道以支持AI应用

多年来，企业一直为事务处理（OLTP）和分析（OLAP）数据维护各自独立的系统，即便这意味着数据需要在两套系统之间频繁流转。然而，随着自主智能体和AI应用的兴起，这些系统既需要即时访问数据，自身又会持续产生大量运营数据，维护独立系统的成本与复杂性问题由此充分暴露。

行业的反应相当迅速。数据仓库与数据库厂商纷纷提出各自的数据孤岛整合方案。近几周内，Databricks发布了LTAP，EDB推出了融合分析方案，而Snowflake在去年底也推出了pg_lake，这些方案均以不同的技术路径，致力于将事务、分析与AI工作负载整合到更紧密的协作关系中。

如今，分布式PostgreSQL服务商pgEdge也加入这一赛道。该公司推出了ColdFront的测试版——一种PostgreSQL原生的冷热数据分层架构。该架构可自动将较旧的数据迁移至Apache Iceberg对象存储，同时保持PostgreSQL作为应用程序唯一需要交互的数据库。在ColdFront的架构体系中，"热数据"指较新的数据，"冷数据"则指较旧的数据。

分析师认为，将PostgreSQL保留为主要交互界面，是ColdFront区别于该领域其他新兴架构的核心所在，也体现了各方在数据重心选择上的根本差异。

HFS Research高管研究负责人Ashish Chaturvedi指出：Databricks的LTAP让运营应用保持连接到执行分析和AI的湖仓；EDB保留PostgreSQL作为运营数据的权威来源，同时通过Iceberg向分析引擎开放数据；Snowflake的pg_lake则将PostgreSQL数据直接写入Iceberg，使PostgreSQL和Snowflake都能查询同一份数据。

而ColdFront的做法截然不同——它将Iceberg仅作为PostgreSQL背后的透明存储层，自动将旧数据从数据库中迁出，同时让应用程序继续使用相同的表和SQL语句。

pgEdge联合创始人Phillip Merrick表示，这种设计带来的结果是：针对近期数据的查询仍在PostgreSQL上执行，而涉及历史记录的请求则通过DuckDB嵌入式分析引擎透明处理，应用程序无需改动SQL，也无需引入ETL管道或独立查询路径。

这也意味着，存储在Iceberg中的旧记录可以通过PostgreSQL直接更新，无需修改应用程序，实现了Merrick所说的"可写冷数据层"。

这一可写冷数据层对于寻求平衡数据本地化、数据主权、合规要求以及智能体时代日益增长的运营需求的企业而言，具有相当的吸引力，尤其是因为竞争方案通常不得不在上述目标中做出取舍。

IT咨询公司Kanerika首席分析官Amit Chandak表示，随着企业为满足审计和监管要求而持续留存AI应用产生的历史运营数据，它们越来越需要具备修正、删除或变更记录的能力——例如为遵守数据保护和隐私法规，即便相关数据已迁移至低成本存储，这一需求依然存在，而其他竞争方案往往使这一过程更加复杂。

Chaturvedi表示，ColdFront能够简化这些流程："在大多数数据分层系统中，冷数据（旧数据）是只读的，因此一旦收到针对归档数据的GDPR删除请求，就意味着要经历还原、删除、重新归档的流程，往往耗费半天时间。而ColdFront的架构允许通过一条SQL语句直接对归档记录执行UPDATE和DELETE操作。"

他还指出，各竞争架构的取舍各有不同：Databricks要求企业以专有湖仓作为运营核心；Snowflake需要应用程序区分PostgreSQL表和分析表；EDB则仍需将归档数据回迁至活跃的PostgreSQL中才能修改。

Info-Tech Research Group顾问研究员Igor Ikonnikov表示，这些取舍对受监管行业尤为关键。金融服务、医疗和政府领域的企业越来越希望将敏感运营数据保留在自有可控的基础设施上，同时保留修改历史记录的能力，以满足不断演变的合规义务。

尽管各家架构存在显著差异，但所有厂商都在技术栈的另一层面上掩盖着一个值得CIO重点关注的趋势——对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目录的治理。这四种方案都向Iceberg写入数据，但使用的目录各不相同，跨厂商的互操作性至今仍是一个悬而未决的问题。当来自不同系统的智能体需要查询同一批Iceberg表时，目录联邦将成为真实存在的运营挑战。"

Q&A

Q1：ColdFront是什么？和其他OLTP/OLAP融合方案有什么区别？

A：ColdFront是pgEdge推出的一种PostgreSQL原生冷热数据分层架构测试版，可自动将旧数据迁移至Apache Iceberg对象存储，同时保持PostgreSQL作为应用唯一交互界面。与Databricks LTAP、EDB融合分析、Snowflake pg_lake相比，ColdFront的核心差异在于：它将Iceberg仅作为PostgreSQL背后的透明存储层，应用程序无需改动SQL或引入ETL管道，而且冷数据支持直接通过PostgreSQL执行更新和删除操作，实现"可写冷数据层"。

Q2：ColdFront的"可写冷数据层"对企业合规有什么帮助？

A：在大多数数据分层系统中，冷数据是只读的，如果收到GDPR删除请求，需要经过还原、删除、重新归档等流程，耗时较长。ColdFront允许通过一条SQL语句直接对归档记录执行UPDATE和DELETE操作，大幅简化合规处理流程。这对金融、医疗、政府等受监管行业尤为重要，企业可在不改变应用程序的前提下满足数据保护和隐私法规要求。

Q3：多个OLTP/OLAP融合方案都依赖DuckDB，这会带来什么风险？

A：ColdFront、Snowflake pg_lake和Databricks Lakebase在分析处理环节均依赖DuckDB，DuckDB已成为新一代PostgreSQL-Iceberg架构中事实上的嵌入式分析引擎。这种集中依赖带来了集中风险——一旦DuckDB出现许可变更、安全漏洞、性能瓶颈或治理问题，影响将同时波及多款产品。因此，CIO应深入了解这些共享组件的成熟度与发展路线图，提前做好风险评估。