多年来，企业一直将事务处理（OLTP）和分析（OLAP）数据分置于独立的系统中，即便这意味着数据要在两者之间来回迁移。然而，自主代理和AI应用的兴起——它们需要即时访问数据，同时自身也在不断生成海量操作数据——彻底暴露了维护这些割裂系统的成本与复杂性。

　　行业的反应来得又快又猛。过去几周内，数据仓库和数据库厂商纷纷拿出了各自的“破壁”方案：Databricks推出了LTAP（Lake Transactional/Analytical Processing），EDB推出了融合分析（Converged Analytics），去年底Snowflake发布了pg_lake——每一家都在为打通事务、分析与AI工作负载提供不同的蓝图。

　　现在，轮到了分布式PostgreSQL提供商pgEdge。

　　冷热分层，但“冷”不再是“只读”

　　6月18日，pgEdge正式宣布推出ColdFront的测试版。这是一套PostgreSQL原生的冷热数据分层架构：自动将冷数据（即旧数据）迁移至Apache Iceberg对象存储，同时让PostgreSQL继续作为应用程序唯一需要交互的数据库。

　　将PostgreSQL作为主要接口，正是ColdFront与同行最大的不同。

　　HFS Research的执行研究负责人Ashish Chaturvedi分析道：Databricks的LTAP将操作应用连接到执行分析与AI的湖仓；EDB将PostgreSQL作为操作数据源，通过Iceberg向分析引擎暴露数据；Snowflake的pg_lake则将PostgreSQL数据直接写入Iceberg，让PostgreSQL和Snowflake都能查询同一份数据。

　　而ColdFront的做法是：将Iceberg仅视为Postgres背后的透明存储层，自动将旧数据移出数据库，同时让应用程序继续使用同一张表和同样的SQL。

　　pgEdge联合创始人Phillip Merrick表示，针对热数据的查询继续在PostgreSQL上运行，而对冷数据的请求则通过DuckDB的嵌入式分析引擎透明执行，应用程序无需引入ETL管道、无需单独的查询路径、也无需任何代码变更。

　　更重要的是，ColdFront的冷层是“可写”的——存储在Iceberg中的冷数据可以通过PostgreSQL直接执行UPDATE和DELETE，无需将数据“回迁”到热存储。

　　为什么“冷可写”如此重要

　　这个“冷可写层”可能会引起那些需要在数据驻留、主权、监管合规与AI时代日益增长的操作需求之间寻找平衡的企业的共鸣。

　　IT咨询公司Kanerika的首席分析官Amit Chandak指出，随着企业为审计和监管目的保留越来越多AI应用生成的历史操作数据，它们越来越需要在数据转移到低成本存储后，仍然能够更正、删除或修改记录——例如遵守GDPR等数据保护和隐私法。而竞争对手的方案在这方面往往更为复杂。

　　Chaturvedi进一步解释：“在大多数分层系统中，冷数据是只读的，因此GDPR对存档数据的删除请求意味着‘恢复-删除-重新归档’，这是半天的工作量。ColdFront的架构允许你通过一条SQL语句直接更新和删除已归档的行。”

　　pgEdge官方也给出了同样的例证：针对五年前归档数据的GDPR删除请求，在ColdFront中就是一条SQL语句——而不是“恢复到热存储、删除、重新归档、再验证”的复杂循环。

　　Info-Tech Research Group的顾问Igor Ikonnikov表示，这些权衡对受监管行业尤为重要。金融服务、医疗保健和政府企业越来越希望在客户控制的基础设施上保留敏感的操作数据，同时保留修改历史记录以应对不断变化的监管义务。

　　DuckDB：所有厂商都在依赖的“隐形引擎”

　　尽管各家架构不同，但分析师们注意到一个正在浮现的趋同点：对DuckDB的依赖日益增加。

　　Ikonnikov指出：“ColdFront使用DuckDB对存储在Iceberg中的数据进行查询。Snowflake的pg_lake通过pgduck_server路由Iceberg查询，Databricks的Lakebase在内部也依赖DuckDB进行部分分析处理。因此，DuckDB正在迅速成为新一代PostgreSQL-Iceberg架构的事实上的嵌入式分析引擎。”

　　pgEdge官方也明确表示，ColdFront将OLTP事务（全速PostgreSQL）、分析查询（DuckDB列式引擎速度）和AI工作负载（访问完整数据历史）三种工作负载统一在同一个表名下、同一条SQL中。

　　但这种日益增长的依赖也造成了分析师所说的集中风险：“如果DuckDB面临许可变更、安全漏洞、性能瓶颈或治理问题，影响将同时波及多个产品。”因此，CIO应该关注这些架构所依赖的共享组件的成熟度和路线图。

　　CIO该如何选择？

　　然而，共享组件的相似性并不会让评估变得更容易。

　　Moor Insights & Strategy的首席分析师Michael Leone表示，大多数企业已经建立了数据架构。他建议CIO应根据数据、开发人员和操作工作流当前所在的位置来评估这些平台，而不是假设某一种架构适合每个环境。

　　对于仍在定义长期数据战略的企业，Leone建议首先在Iceberg上标准化——因为所有四家厂商都支持这一开放表格式，企业将保留灵活性，日后更换前端数据库或分析平台也无需迁移底层数据。

　　不过，Ikonnikov也提出了警告：“问题在于Iceberg目录治理。四种方法都写入Iceberg，但它们使用不同的目录，供应商之间的互操作性仍是一个未解决的问题。当来自不同系统的代理需要查询相同的Iceberg表时，目录联合就成为一个真正的操作挑战。”

　　pgEdge ColdFront目前以测试版形式提供，用于预生产测试和评估。运行于标准上游PostgreSQL 16、17和18之上，冷数据以标准Apache Iceberg（Parquet格式，S3兼容对象存储）存储，可被Spark、Trino、DuckDB、Snowflake或Databricks读取，且不依赖ColdFront。pgEdge声称可降低高达90%的存储成本，并计划在2026年下半年将ColdFront捆绑至pgEdge Enterprise Postgres并集成到pgEdge Cloud中。

　　数据仓库与数据库的边界正在消失。而这一次，PostgreSQL生态没有缺席。

作者：Anirban Ghoshal