多年来，企业一直在为事务处理（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
第一个问题：ColdFront到底是什么？和其他OLTP/OLAP融合方案有什么区别？
简单来说，ColdFront是pgEdge推出的一种PostgreSQL原生冷热数据分层架构测试版，可以自动把旧数据迁移到Apache Iceberg对象存储，同时保持PostgreSQL作为应用唯一交互界面。和Databricks LTAP、EDB融合分析、Snowflake pg_lake相比，ColdFront的核心差异在于：它把Iceberg只当作PostgreSQL背后的透明存储层，应用程序无需改动SQL或引入ETL管道，而且冷数据支持直接通过PostgreSQL执行更新和删除操作，实现了“可写冷数据层”。
第二个问题：ColdFront的“可写冷数据层”对企业合规有什么实际帮助？
在大多数数据分层系统中，冷数据是只读的，如果收到GDPR删除请求，需要经过还原、删除、重新归档等流程，耗时较长。ColdFront允许通过一条SQL语句直接对归档记录执行UPDATE和DELETE操作，大幅简化合规处理流程。这对金融、医疗、政府等受监管行业尤为重要，企业可以在不改变应用程序的前提下满足数据保护和隐私法规要求。
第三个问题：多个OLTP/OLAP融合方案都依赖DuckDB，这会带来什么风险？
ColdFront、Snowflake pg_lake和Databricks Lakebase在分析处理环节均依赖DuckDB，DuckDB已成为新一代PostgreSQL-Iceberg架构中事实上的嵌入式分析引擎。这种集中依赖带来了集中风险——一旦DuckDB出现许可变更、安全漏洞、性能瓶颈或治理问题，影响将同时波及多款产品。因此，CIO应深入了解这些共享组件的成熟度与发展路线图，提前做好风险评估。