pgEdge杀入 “OLTP+OLAP+AI”混战，ColdFront 到底有啥不一样？
在数据库过往二十年发展中，很多企业都在做同一件事，那就是把 OLTP（事务处理）和 OLAP（分析处理）拆成两套系统。原因很简单：你总不能让跑着银行转账的数据库，同时去跑年度报表吧？那跟让 F1 赛车去拉货没什么区别！
于是，ETL 管道、数据复制、CDC 同步……一套套“组合拳”打下来，数据在系统之间来回搬运，成本高、延迟大、运维累。即便如此，大家也没有任何异议，因为早已习惯了，觉得数据库“本来就该是这样”。
但是今天，Agentic AI时代来了。
Agent这个属于新时代的“产物”，可以不吃不喝、不睡觉、不放假，每时每刻都在读写数据、生成数据、消费数据。它们不懂什么叫“等 ETL 跑完”，也不会体谅 DBA 周末还要加班修管道。当数据库用户从“人”转向“Agent”，原来那套架构显然就绷不住了。
Agentic AI时代的突围
过去一段时间里，整个行业像被按下了加速键：Databricks 推出 LTAP（数据湖事务分析处理，一种旨在将运营和分析工作负载统一到单一数据副本上的新架构），EDB 推出融合分析（该方法比Databricks的LTAP提供了更可预测的成本）。去年年底， Snowflake 也搞了 pg_lake（使开发者和数据工程师能够直接从PostgreSQL读取数据和写入Apache Iceberg表，从而省去数据提取和迁移环节）。大家拼的不是谁技术更炫，而是谁能让 AI 应用更快地拿到数据。
现在，又一位玩家入场了。分布式 PostgreSQL 厂商 pgEdge 发布了 ColdFront 测试版，这是一套 PostgreSQL 原生的冷热数据分层架构，能把老数据自动搬到 Apache Iceberg 对象存储里，同时让应用仍然只跟 PostgreSQL 打交道。
听起来好像跟别人的方案差不多？别急，对比后，你会发现明显的不同！
ColdFront到底有啥不一样？
先看其他几家在干什么。
Databricks 的 LTAP 是以湖仓为中心，运营应用连接到湖仓，分析和 AI 都在湖仓里完成，数据重心在湖仓。EDB 的融合分析是把 PostgreSQL 当作操作层的“唯一真实来源”，通过 Iceberg 把数据暴露给 ClickHouse、Spark 等分析引擎。数据重心在 PostgreSQL，但分析引擎是独立的。Snowflake 的 pg_lake 直接把 PostgreSQL 数据写入 Iceberg，让 PostgreSQL 和 Snowflake 都能查同一份数据。数据重心在……应该是两边都算？
而ColdFront 的思路完全不同！HFS Research 的执行研究负责人 Ashish Chaturvedi 点出了关键差异：“ColdFront 只把 Iceberg 当作 PostgreSQL 后端的一个透明存储层，自动把老数据移出数据库，但应用依然使用相同的表和相同的 SQL。”
翻译成人话：其他方案是让 PostgreSQL 和数据湖“做朋友”，ColdFront 是让数据湖“给 PostgreSQL 当仓库”。
数据重心牢牢地扎在 PostgreSQL 这一侧。应用层完全无感，你连 SQL 都不用改，连表名都不用换。老数据搬走了，但查询老数据的请求会被透明地交给嵌入式的 DuckDB 分析引擎去执行。
pgEdge 联合创始人 Phillip Merrick 说得挺直白：“多年来供应商一直声称自己无缝整合了分析、事务和 AI 工作负载。ColdFront 终于为 Postgres 做到了这一点，没有妥协，没有专有锁死。”
“冷数据可写”为什么重要？
分层存储这事不新鲜。但大多数分层方案有一个默认设定：冷数据是只读的。
为什么？因为老数据一旦搬到廉价存储上，再想改就麻烦了。很多方案需要你先把数据“恢复”回热存储，改完再“重新归档”，一套流程走下来，半天就没了。
ColdFront 最反直觉的设计就是：冷数据默认可写。
举个例子：GDPR 要求删除五年前的一条客户记录。在 ColdFront 里，这就是一条 SQL 语句的事。不需要“恢复-删除-重新归档-重新验证”那一套折腾。
Kanerika 的首席分析官 Amit Chandak 指出，随着企业为了满足审计和监管要求保留越来越多 AI 应用生成的历史数据，更正、删除或修改这些记录的能力变得越来越重要，即便数据已经搬到了廉价存储上。
Info-Tech Research Group 的顾问研究员 Igor Ikonnikov 也点明了这层意思：金融服务、医疗、政府领域的企业，越来越希望在客户控制的基础设施上保留敏感运营数据，同时保留修改历史记录的能力，以满足不断变化的合规要求。
说白了，数据可以老，但不能死。审计来了要能查到，删数据要能删掉，改错要能改回来，不管这数据是昨天写的还是十年前写的。
四家方案，四种哲学
把这几家的方案放在一起看，能品出完全不同的产品哲学：
Chaturvedi 的总结很到位：Databricks 要求企业采用其专有的湖仓一体架构作为运营中心；Snowflake 要求应用区分 PostgreSQL 表和分析表；EDB 仍然要求修改归档数据前先恢复到活跃的 PostgreSQL 实例。
而 ColdFront 的选择是：把复杂性藏在 PostgreSQL 后面，应用层什么都别动。
DuckDB 正在成为“隐藏的赢家”
还有一个有意思的细节。
这几家虽然在架构上打得不可开交，但在技术栈底层却呈现出一种奇怪的趋同，对 DuckDB 的依赖正在不断增加。
Ikonnikov 指出：“ColdFront 使用 DuckDB 对 Iceberg 中的数据执行查询；Snowflake 的 pg_lake 通过 pgduck_server 实现Iceberg 查询；Databricks 的 Lakebase 也依赖 DuckDB 进行部分分析处理。可以说，DuckDB 正迅速成为新一代 PostgreSQL-Iceberg 架构中事实上的嵌入式分析引擎。”
与此同时，分析师也提醒了一个“集中风险”：如果 DuckDB 哪天出了许可证变更、安全漏洞或性能瓶颈，会同时波及多个产品，数据库开发团队得权衡利弊，有效评估这个组件的成熟度和未来发展路线图。
开发者该怎么选？
问题是，面对不同的数据架构，开发者该怎么选？
Moor Insights & Strategy 的首席分析师 Michael Leone 给了一个务实的建议：大多数企业已经有了现成的数据架构，不要假设某一种方案适用于所有环境。应该根据企业当前的数据现状、开发人员习惯和运营工作流来评估。
如果还在制定长期数据战略，他建议先标准化 Iceberg 开放表格式。因为这四家都支持 Iceberg，未来换前端数据库或分析平台的时候，底层数据不用迁移。
不过 Ikonnikov 补了一刀：Iceberg Catalog 的治理是个坑。虽然四家都往 Iceberg 写数据，但用的是不同的 Catalog，不同供应商之间的互操作性还存在一些问题。当来自不同系统的 AI Agent需要查询同一个 Iceberg 表时，Catalog 的联邦与互通会成为真正的运营挑战。
换句话说：格式统一了，但“目录”还没统一。 这大概就是开源世界的常态，标准大家认，但实现各玩各的。
写在最后
从数据应用现状来看，大多数企业都在用 SSD 的价格存着几乎从来不碰的数据，同时还要花大量工程时间去管理哪些该留、哪些该删、业务需要的时候怎么恢复老数据。ColdFront给数据库开发团队带来的新视角是，可以自动处理数据的整个生命周期，应用继续用同样的 SQL，存储账单会大幅下降。
至于，数据应用成本，是否真的会下降？预估的节省成本，能不能兑现？这要另说！但至少，“搬数据”这件事终于不用让应用开发者操心了。尤其对于那些被 AI 应用逼着天天扩容的团队来说，这大概算是个好消息。
