给AI造数据库的，先拿了1.5亿美元

2026年10月2日，靠开源PostgreSQL起家的Supabase宣布完成1.5亿美元融资，领投方是新加坡主权基金GIC，Alphabet旗下CapitalG跟投，同一天它还宣布收购数据库创业公司Turso。几乎前后脚，分析型数据库ClickHouse抛出一份报告：在CostBench基准下，其对Snowflake的性能成本比高出412倍。

两条新闻看似不相干，其实指向同一个判断：数据库的采购者，正在从"人"变成"AI"。谁先按这个前提重造产品，谁就先拿到下一轮钱。本文拆解这两件事背后的产业逻辑。

💰 一笔主权基金领投的数据库融资，本身就是信号

在基础设施投资普遍收紧的当下，一笔由主权基金领投的数据库融资，本身就是信号。

先把事实摆清楚。据SiliconANGLE报道，Supabase本轮融资1.5亿美元，由新加坡政府投资公司GIC领投，Alphabet旗下成长期基金CapitalG、IronArc和SquarePeg参与。这笔钱的到位，和另一件事打包宣布：Supabase已同意收购同赛道数据库创业公司Turso，收购金额未披露。

这张投资人名单值得细看。主权基金入场，意味着数据库被当作超长周期的基础设施资产来配置，而不是一轮快进快出的赛道博弈；CapitalG的加入，则暗示大厂生态对这家人公司的认可。做过数仓的人都知道，数据库是一门"慢生意"——技术护城河要靠十年积累，商业回报要靠续费率堆出来。主权基金的钱恰好匹配这种节奏。

更关键的产业逻辑在于：Supabase本质上是把开源PostgreSQL变成托管服务卖给开发者。过去十年，这套"开源内核+云托管"的模式已经被反复验证，但Supabase选择在此刻主动改写自己的叙事——不再是"给开发者的Postgres"，而是"给AI的数据库基础设施"。融资和收购同一天官宣，资本市场愿意为这个新叙事买单。

🤖 收购Turso：给Agent配一张随身床位

Agent不用年卡，它按需开房。

想象一个典型的AI Agent的工作流程：接到任务，拆解步骤，读写中间状态，检索资料，生成结果，然后这个任务就结束了。注意最后一环——很多Agent任务的生命周期可能只有几分钟甚至几秒钟，但它全程需要数据库：存状态、存记忆、存临时数据。

这套负载特征和人类开发者完全不同：数量极大、单个极小、生命周期极短。一个Agent应用背后可能同时跑着成千上万个任务实例，每个实例都需要一个隔离的数据库环境。用传统方式给每个任务开一个全功能数据库实例，成本和运维都会失控。

这正是Supabase收购Turso的意图所在。Supabase官方的说法非常直白：收购Turso是为了"构建agentic AI的数据库基础设施"。Turso是数据库创业公司，业内普遍将其与轻量级嵌入式数据库路线联系在一起——和Supabase主打的PostgreSQL全功能托管恰好互补：一个覆盖常驻的应用主库，一个覆盖随任务生灭的轻量库。

据多位接近基础设施投资圈的人士观察，这一轮"数据库为Agent重构"的故事，已经成为新的融资叙事模板。但对Supabase来说，这不只是叙事：产品形态的补齐是实打实的。当你的客户从"写代码的人类"变成"写代码的AI加被调度的Agent"，数据库的产品边界、计费方式、部署粒度都要重做一遍。收购，是重造最快的方式。

📊 412倍：另一条战线上的成本革命

当查询量被Agent放大一个量级，性能每美元就成了生死线。

ClickHouse公布的对比数据更刺眼：在CostBench基准测试中，ClickHouse Cloud相对Snowflake实现了412倍的性能成本比优势。这不是简单的"谁跑得快"，ClickHouse官方对差距的归因框架是完整链路的：从新数据到达，到快速答案返回，每一个环节的效率损耗累积起来，最终体现在每一美元买到的性能上。

对这组数字要冷静看待——厂商自家的基准测试，天然有利于自家的架构设计，412倍是一个极端场景下的峰值差距，不代表所有负载下的普遍表现。但它揭示的趋势是真实的：分析型数据库的竞争语言，正在从"跑分"切换到"性能每美元"。

为什么是现在？因为AI改变了查询量的分母。Agent驱动的工作负载，查询频次可能是人工分析师的几十上百倍；一个跑在Agent上的应用，夜里也在跑查询。当查询量乘上一个量级，单位查询成本上的差距就会被指数级放大——过去Snowflake账单上不起眼的零头，会变成AI创业公司活下去还是死掉的分界线。做过实时管道的工程师都懂：成本不是采购时的一次性决策，而是每天凌晨账单出来时的心跳。

🧭 分水岭：数据库开始按"谁来用"重新分类

数据库的教科书分类法，正在被改写。

过去几十年，数据库按工作负载分类：OLTP管事务，OLAP管分析，中间夹着HTAP的争论。但Agent时代的分类维度变了——第一个问题不再是"什么负载"，而是"谁来用"。给人类开发者用的数据库，追求稳定的连接、完备的工具链、舒适的控制台；给Agent用的数据库，追求API优先、秒级开通、用完即走、成本按毫秒计。

这张表解释了Supabase的动作顺序：先用PostgreSQL托管服务占住"AI应用默认底座"的位置——在AI编程工具大量生成应用的当下，Postgres已经是被代码助手默认推荐最多的数据库之一；再用Turso补上Agent侧的轻量形态。两步走完，它同时覆盖了表格里的两列。

资本也在按这个逻辑投票。GIC领投一家数据库公司，押注的不是Postgres本身，而是"Agent经济需要自己的数据基础设施"这个前提。业内现在流传一种说法：下一代数据库公司的估值锚，不再是存储了多少TB数据，而是支撑了多少Agent任务。这个说法未必准确，但方向感是对的。

⚠️ 融资不等于赢：三道坎还在前面

拿到钱的欢呼之后，真正难的在执行侧。

第一道坎是整合。Turso的收购金额未披露，团队整合、技术路线合并、开源社区迁移，每一样都要消耗至少两三个季度。数据库行业里"收购之后产品失焦"的案例不少见，双线产品如何共享账户、计费和网络层，是对工程团队的真考验。

第二道坎是巨头。云厂商一直在做"开源数据库的托管平替"，Alphabet自身就深度经营Postgres托管服务——CapitalG一边投资一边自家也有竞争产品，这种微妙关系本身就需要Supabase小心翼翼地维护边界。

第三道坎是需求兑现的节奏。"Agent需要海量临时数据库"目前还是一个前瞻性判断，真实的生产级Agent工作负载规模有多大、付费意愿有多强，还需要一两个完整周期来验证。如果Agent应用的商业化不及预期，为它重造的数据库基础设施，就会面临产能过剩的问题。

🔭 写在最后

数据库行业几十年没变过的一条铁律是：跟着应用的形态走。PC时代成就了关系型数据库，移动互联网成就了NoSQL，云时代成就了托管化和存算分离。现在轮到AI了——当采购者从人变成Agent，从按月用到按秒用，产品的每一个假设都要重写。

Supabase的1.5亿美元和Turso收购，ClickHouse的412倍性能成本比，是这轮重写的第一批注脚。可以预见，未来12个月会有更多数据库公司宣布自己"为Agent而生"。但判断谁是真玩家只有一个标准：看它的产品是真的为毫秒级的任务生命周期做了工程重构，还是只改了融资BP上的一个形容词。工程落地，永远是这个行业的照妖镜。