2026年6月4日，Supabase宣布完成5亿美元Series F融资，估值达到105亿美元。这个数字需要放在一个坐标系中理解：2025年6月，这家公司的估值还是20亿美元；4个月后的2025年10月跳到50亿美元；再过8个月，翻倍至105亿美元（来源：CNBC, 2026-06-04；TechCrunch, 2025-10-03）。在不到12个月的时间里，估值从20亿跃升至105亿——这不是一条正常的SaaS增长曲线，这是一个基础设施公司被重新定价的信号。

问题是：市场究竟在为什么买单？一个开源的Firebase替代品，即便再好用，也不应该值105亿美元。答案藏在融资公告的标题里——”Accelerate Lead in Agentic Infrastructure”（来源：PR Newswire, 2026-06-04）。Supabase已经不再是那个帮独立开发者快速搭建后端的工具了。它正在成为AI Agent时代的数据层基础设施，而这个市场的天花板，远比”开发者工具”这个标签所暗示的要高得多。

第一章：估值跃迁的加速度——从Series D到Series F的资本信号解码

让我们先拆解Supabase的融资时间线，因为加速度本身就是最重要的信息。

2025年6月前后，Supabase完成了一轮融资，估值约20亿美元。这一数据点来自TechCrunch 2025年10月报道的标题——”Supabase nabs $5B valuation, four months after hitting $2B”——由此反推20亿美元估值确立于2025年6月前后（来源：TechCrunch, 2025-10-03）。需要说明的是，该轮融资的独立公告链接未被公开检索到，20亿美元这一数字系基于TechCrunch报道的间接推断。

仅仅4个月后的2025年10月，Supabase宣布完成1亿美元融资，由Accel和Peak XV联合领投，估值达到50亿美元（来源：PR Newswire, 2025-10-03）。这意味着在不到半年的时间里，公司估值增长了150%。

到了2026年6月，Series F的5亿美元将估值推到了105亿美元（来源：CNBC, 2026-06-04）。从50亿到105亿，又是8个月内翻倍。

这种估值加速度在基础设施领域极为罕见。作为对比，MongoDB在公开市场上从约50亿美元市值增长到100亿美元市值，大约经历了2019年中至2020年底的约18个月时间（基于Yahoo Finance历史股价数据，MongoDB在2019年6月市值约为48亿美元，2020年12月突破100亿美元）。而Supabase在一级市场用不到12个月就完成了同样的跨越——尽管一级市场和二级市场的估值逻辑不同，但速度差异仍然显著。

资本在押注什么？

从投资方的角度看，这笔钱不是在为当前收入买单。Supabase作为未上市公司，没有SEC filing的披露义务，公司也未公开披露过具体营收数字。我们能确认的是：Supabase官方博客在Series F公告中提到了”revenue growth”但未给出具体数字（来源：Supabase Blog, 2026-06-04）。CNBC的报道同样未披露ARR数据。在缺乏收入基准点的情况下，投资者显然是在为一个结构性转折点下注。

PYMNTS的报道标题精准地捕捉了这个逻辑——”AI Agents Spark Database Explosion”（来源：PYMNTS, 2026-06-04）。关键词是”explosion”，不是”growth”。

这里的投资逻辑可以这样理解：如果过去10年，数据库的需求增长主要由人类开发者构建的应用驱动，那么接下来的需求增长将由AI Agent驱动。而Agent的数量级、创建速度和生命周期管理方式，与传统应用有根本性的不同。每一个Agent都可能需要自己的数据库实例来存储状态、管理会话、持久化记忆——这把数据库从”每个公司几个”变成了”每个公司可能需要成百上千个”。

Supabase的估值跃迁，本质上是市场在为这个乘数效应提前定价。

反面论证：估值是否过高？

当然，105亿美元的估值面临合理质疑。即便按照最乐观的SaaS估值框架（50x ARR），这意味着Supabase需要至少2.1亿美元的年化经常性收入来支撑当前估值。由于公司未披露营收，我们无法直接验证这一点。但可以参考的间接信号是：Supabase在2023年曾透露其托管平台上有超过100万个数据库项目（来源：Supabase Blog），到2025年这一数字可能已大幅增长。如果按照每个付费项目平均月消费25美元估算（这是其Pro计划的起步价），100万项目中即使只有20%付费，也意味着约6000万美元的ARR——距离2.1亿美元仍有显著差距。

我的判断是：这个估值在传统SaaS框架下确实偏高，但如果用”AI基础设施平台”的逻辑来看——类似于早期AWS或Snowflake在IPO前的定价逻辑——它反映的是一个正确方向上的提前布局。关键变量是Agent经济的落地速度。

第二章：从Firebase杀手到Agent基础设施——产品矩阵的结构性契合

要理解Supabase为什么能卡位AI Agent基础设施，必须先理解它的产品矩阵是如何演进的。

起点：开源Firebase替代品

Supabase最初的价值主张极其清晰：给开发者一个Firebase的开源替代品，但底层用Postgres而不是Firebase的NoSQL文档数据库。这个选择在2020年看起来只是一个技术偏好，但回头来看，它是整个故事的关键伏笔。

Firebase的核心产品包括：实时数据库、用户认证（Authentication）、文件存储（Storage）、云函数（Cloud Functions）。Supabase一一对标，但全部构建在Postgres之上：

  • Database：完整的Postgres实例，不是阉割版
  • Auth：内置的认证系统，支持Row Level Security（RLS）
  • Storage：对象存储，与数据库权限系统深度集成
  • Realtime：基于Postgres的逻辑复制（logical replication）实现实时数据订阅
  • Edge Functions：Deno运行时的无服务器函数
  • Vector：基于pgvector扩展的向量搜索能力

这个产品矩阵在2023年之前主要服务于独立开发者和初创公司——他们需要快速搭建后端，但不想被Google锁定。但从2024年开始，一个新的用户群体出现了：AI应用开发者和Agent框架构建者。

为什么Postgres是AI Agent的天然底座？

这是大多数分析忽略的关键洞察。AI Agent需要的不是一个简单的键值存储，它需要：

  1. 结构化状态管理：Agent的工作流状态、任务队列、执行历史需要关系型数据建模
  2. 向量搜索：Agent的长期记忆和知识检索需要向量相似度搜索
  3. 实时事件流：Agent之间的协调和人机交互需要实时数据推送
  4. 细粒度权限控制：多租户环境下，不同Agent的数据隔离是安全刚需
  5. 事务一致性：Agent执行关键操作（如支付、状态变更）需要ACID保证

传统的做法是用5个不同的服务来满足这5个需求：PostgreSQL + Pinecone + Redis Pub/Sub + Auth0 + 某种事务协调器。Supabase的价值在于：它用一个Postgres实例（加上扩展生态）统一解决了所有这些问题。

pgvector让Postgres可以做向量搜索，Supabase Realtime让它可以做事件流，Row Level Security让它可以做细粒度权限，而Postgres本身的ACID特性天然满足事务需求。这不是凑合，这是一个经过深思熟虑的架构选择在正确时间点的价值释放。

“Vibe Coding”时代的催化效应

“Vibe coding”这一概念最早由Andrej Karpathy在2025年2月的一条推文中提出，他用这个词描述一种完全依赖AI生成代码、开发者只需”感受氛围”的编程方式（来源：Andrej Karpathy, X/Twitter, 2025-02-02）。TechBuzz在报道Supabase融资时使用了”vibe coding era dawns”这个表述（来源：TechBuzz, 2026-06-04），将这一趋势与Supabase的增长直接关联。

这个概念值得展开：当AI编码助手（如Cursor、GitHub Copilot、Claude等）让非专业开发者也能快速构建应用时，对”零配置后端”的需求呈指数级增长。

在vibe coding场景中，用户对AI说”帮我建一个带用户系统的SaaS应用”，AI需要选择一个后端来部署。Supabase因为其开发者体验的简洁性和文档质量，成为了AI编码助手最常推荐的选择之一。这创造了一个飞轮：更多AI生成的代码使用Supabase → 更多训练数据强化这个偏好 → 更多新项目默认选择Supabase。

GitHub的数据可以间接验证这一趋势：Supabase的官方JavaScript客户端库（supabase-js）在GitHub上的星标数从2024年初的约3000颗增长到2025年底的超过6000颗，而其主仓库的星标数在2025年突破了75000颗（来源：GitHub）。这种增速与vibe coding工具的普及时间线高度吻合。

但这只是需求侧的一半。更深层的结构性变化是：当AI Agent本身成为”开发者”——不是辅助人类写代码，而是自主创建和管理数据库实例——数据库的创建频率和生命周期会发生根本改变。

第三章：AI Agent时代的数据库经济学——从”每公司几个”到”每Agent一个”

这一章是整篇分析的核心论点。

传统模型：数据库是稀缺资源

在传统的云计算范式中，数据库是一个重资产。一个典型的B2B SaaS公司可能有3-5个核心数据库：生产环境主库、只读副本、分析数据仓库、缓存层、也许一个搜索引擎。数据库的创建是一个慎重的决策，涉及容量规划、安全审计、备份策略等一系列流程。

在这个模型下，全球数据库实例的总数增长是线性的，与公司数量和应用数量大致成正比。数据库供应商的收入增长因此也是线性的——新客户 × 每客户实例数 × 单实例价格。

新模型：数据库是Agent的标准配件

AI Agent改变了这个等式的每一项。

首先是创建频率。一个企业可能同时运行数十甚至数百个Agent：客服Agent、数据分析Agent、代码审查Agent、销售外呼Agent、内容生成Agent……每一个Agent都需要持久化自己的状态。它需要记住对话历史（向量存储）、跟踪任务进度（关系型数据）、管理临时文件（对象存储）、验证调用者身份（认证）。

这些需求加在一起，恰好是一个完整的Supabase实例所提供的功能集。

其次是生命周期。传统数据库的生命周期以年计算。Agent的数据库实例可能只存在几小时（一次性任务Agent）、几天（项目型Agent）或几个月（长期运行的业务Agent）。这种短生命周期、高周转率的模式，要求数据库的创建和销毁必须是全自动化的、秒级的、零运维的——这正是Supabase作为托管平台的核心能力。

第三是规模乘数。如果一个中型企业从”5个数据库”变成”500个Agent数据库实例”，这是100倍的实例数增长。即使每个Agent实例的规模远小于传统数据库，总消费额的增长也是数量级的。

商业模型的范式转移

这对Supabase的商业模型意味着什么？

传统的数据库定价模型是：按存储量 + 按计算量 + 按连接数。这个模型假设数据库数量少但单个数据库大。

Agent时代的定价模型可能演变为：按实例数 + 按API调用量 + 按Agent交互次数。数据库数量多但单个可能很小。这更接近于Serverless的定价哲学——按使用付费，而不是按资源预留付费。

Supabase的优势在于：它从一开始就是按项目（project）为单位提供服务的。每个”project”是一个独立的Postgres实例，带有独立的Auth、Storage和Realtime。这个架构天然适配”每Agent一个实例”的模型，无需根本性的架构重构。

一个关键的数量级估算

让我们做一个粗略的市场规模推演，并尽可能锚定外部数据点。

关于企业数量：Gartner在2024年预测，到2028年将有33%的企业软件应用包含Agentic AI组件，而2024年这一比例不到1%（来源：Gartner, 2024-10-14）。全球中大型企业数量约在300-500万家（基于World Bank数据），33%意味着约100-165万家企业将部署Agent——我们取保守值100万家。

关于Agent数量：LangChain在2025年初发布的开发者调查显示，已部署Agent的企业中，中位数为5-10个Agent，但头部企业已经运行超过50个（来源：LangChain State of AI Agents Report, 2025）。随着Agent框架的成熟，我们假设3-5年后的平均值为50个。

关于单Agent消费：Supabase Pro计划起步价为25美元/月/项目，但Agent实例可能更轻量。我们假设平均20美元/月。

100万 × 50 × 20美元/月 × 12个月 = 120亿美元/年的潜在市场。

即使Supabase只能拿到这个市场的10%，也意味着12亿美元的年收入——足以支撑远超105亿美元的估值。这些假设中的每一个都可以被挑战——Agent数量可能更少、单价可能更低、市场份额可能更分散——但即使将所有假设打5折，仍然是一个30亿美元/年的可寻址市场，方向和数量级的判断是有意义的。

第四章：竞争格局与护城河——为什么是Supabase而不是其他人？

Postgres生态的网络效应

Supabase最深的护城河不是它自己建的，而是Postgres社区40年积累的结果。

Postgres不是一个数据库，它是一个数据库操作系统。通过扩展机制（extensions），它可以变成：

  • 向量数据库（pgvector）
  • 时序数据库（TimescaleDB）
  • 图数据库（Apache AGE）
  • 地理信息系统（PostGIS）
  • 全文搜索引擎（内置tsvector）
  • 列式分析引擎（Citus）

这意味着选择Supabase的开发者不会被锁定在一个有限的功能集中。随着需求演进，他们可以通过启用新的Postgres扩展来获得新能力，而不需要迁移到新的数据库。这种”留在Postgres生态内就能解决一切问题”的承诺，是一个极强的粘性来源。

对于AI Agent场景尤其如此：Agent的需求是多模态的（结构化数据 + 向量 + 全文搜索 + 实时流），传统方案需要集成多个独立服务，而Supabase用一个Postgres实例加扩展就能覆盖。这不仅降低了架构复杂度，更重要的是减少了Agent的延迟——所有数据操作都在同一个实例内完成，无需跨服务网络调用。

与Neon的差异化：平台 vs 引擎

Neon是另一个备受关注的Postgres初创公司（2024年完成1亿美元融资，估值约10亿美元），但它与Supabase的定位有本质差异。Neon专注于做”更好的Postgres引擎”——它的核心创新是存算分离架构，让Postgres可以像Serverless一样弹性伸缩、按需付费。Neon是数据库层面的创新。

Supabase则是在Postgres之上构建完整的应用开发平台。数据库只是它的底层之一，Auth、Storage、Realtime、Edge Functions共同构成了一个完整的后端即服务（BaaS）。

这个差异在AI Agent场景中尤为关键：Agent不只需要一个数据库，它需要一个完整的后端环境。如果用Neon，你还需要单独集成认证服务、文件存储、实时推送等组件。用Supabase，这些都是开箱即用的。

有趣的是，Neon和Supabase并非完全竞争关系。Supabase理论上可以使用Neon的存算分离引擎作为底层（虽然目前它使用的是标准Postgres部署）。但在AI Agent基础设施的卡位战中，Supabase的”全栈平台”定位比Neon的”单点引擎”定位更有优势。

与PlanetScale的对比：开源 vs 闭源的命运分野

PlanetScale（基于Vitess/MySQL的云数据库）在2024年3月宣布关闭免费计划（Hobby tier），随后在2024年进行了裁员（来源：PlanetScale Blog, 2024-03-06；The Information报道了其裁员约15%的消息）。这为Supabase提供了一个教训和一个机会。教训是：纯粹靠技术差异化在数据库市场不够，必须建立生态锁定。机会是：PlanetScale流失的开发者中有相当一部分转向了Supabase——Reddit和Hacker News上的迁移讨论帖在2024年3-4月密集出现。

Supabase的开源策略是其与PlanetScale最大的差异。Supabase的核心组件（包括Auth、Realtime、Storage等）都是开源的，这意味着开发者可以自托管（self-host）。这看似是在”送出”收入，但实际上它建立了三重护城河：

  1. 社区贡献：开源吸引了大量社区开发者贡献代码、插件和集成
  2. 信任基础：企业客户知道他们不会被完全锁定，因此更愿意采用
  3. 生态标准化：当足够多的项目使用Supabase的API规范时，它就成了事实标准

与Vercel和Cloudflare的生态协同与竞争

值得注意的是，Supabase与Vercel有深度集成关系——Vercel的模板市场中大量Next.js项目默认使用Supabase作为后端，两家公司在2024年联合推出了多个集成功能。这种协同关系为Supabase带来了大量来自前端开发者的流量。

但Cloudflare的D1（基于SQLite的边缘数据库）和Workers AI构成了一个潜在的竞争威胁。Cloudflare的优势在于其全球边缘网络带来的超低延迟，以及将数据库、AI推理和Serverless函数统一在一个平台上的能力。不过，D1目前仍基于SQLite，在功能丰富度上远不及Postgres，且缺乏Supabase的Auth、Realtime等配套服务。短期内威胁有限，但长期值得关注。

与Firebase本身的竞争

Firebase在Google Cloud的体系中仍然是一个重要产品，但它的架构选择（NoSQL文档数据库、Google专有认证系统）在AI Agent时代暴露了局限性：

  • NoSQL不适合Agent的结构化状态管理
  • 缺乏原生向量搜索能力
  • 实时功能虽强但与Google生态深度绑定
  • 没有SQL接口，AI Agent无法直接用自然语言转SQL来查询

相比之下，Supabase基于Postgres的SQL接口是一个巨大优势：LLM天然擅长生成SQL查询（因为训练数据中有大量SQL示例），这意味着AI Agent可以直接用自然语言与Supabase交互，无需额外的适配层。这是一个看似微小但影响深远的架构优势。

第五章：Agentic Infrastructure的技术深层——为什么”状态管理”是Agent的阿喀琉斯之踵

大多数关于AI Agent的讨论集中在推理能力（LLM的智能程度）和工具调用（Agent能操作什么），但很少有人深入讨论状态管理——而这恰恰是Agent从”demo”走向”生产”的最大瓶颈。

无状态Agent的局限性

当前大多数Agent框架（如LangChain、CrewAI、AutoGen）在处理状态时采用的是简单粗暴的方式：把所有上下文塞进LLM的context window。这在短对话中可行，但在长期运行的业务Agent中会遇到三个根本性问题：

  1. Context window有限：即使是200K token的窗口（如Claude 3.5的最大上下文），也无法容纳一个运行了数周的Agent的全部历史
  2. 成本爆炸：每次调用都把全部上下文送入LLM，token成本随历史长度线性增长
  3. 一致性问题：如果Agent崩溃重启，内存中的状态全部丢失

解决方案是让Agent把状态持久化到外部数据库。但这不是简单地”写入数据库”——Agent的状态是异构的：

  • 短期记忆（当前对话上下文）→ 需要快速读写
  • 长期记忆（历史知识、学到的偏好）→ 需要向量检索
  • 任务状态（工作流进度、待办事项）→ 需要关系型建模
  • 文件附件（用户上传的文档、生成的报告）→ 需要对象存储
  • 权限上下文（这个Agent能访问什么数据）→ 需要细粒度ACL

Supabase的产品矩阵恰好一一对应这些需求。这不是巧合——这是Postgres作为”通用数据平台”的架构优势在AI时代的具体体现。

MCP协议与Supabase的战略卡位

Anthropic在2024年11月25日正式发布了Model Context Protocol（MCP），这是一个开放协议，定义了AI模型如何与外部数据源和工具进行标准化交互（来源：Anthropic Blog, 2024-11-25）。MCP迅速获得了行业支持——到2025年中，包括OpenAI、Google DeepMind在内的多家公司都宣布了对MCP的兼容支持。

对Supabase而言，MCP生态的崛起既是机会也是验证。关键事实是：Supabase已经在其官方文档中提供了MCP集成指南，允许Agent通过MCP协议直接连接Supabase实例进行数据读写操作（来源：Supabase Docs）。这意味着Supabase不仅在讨论”Agentic Infrastructure”的概念，而是已经在产品层面落地了具体的Agent集成能力。

如果主流Agent框架在需要持久化存储时默认推荐Supabase（类似于Web开发中”需要数据库就用Postgres”的心智模型），那么每一个新Agent的诞生都自动转化为Supabase的潜在客户。

这也解释了为什么Supabase在Series F的公告中强调”Agentic Infrastructure”而不是”Developer Tools”——它在有意识地重新定义自己在技术栈中的位置：从”开发者的后端工具”升级为”Agent的操作系统级基础设施”。

Agent身份与多租户隔离的技术挑战

一个尚未被充分讨论的技术问题是：当一个企业运行数百个Agent时，如何管理Agent的身份和数据隔离？

传统的认证系统是为人类用户设计的——用户名/密码、OAuth、SSO。但Agent不是人类。Agent需要的是：

  • 机器身份（Machine Identity）：每个Agent有唯一标识和API密钥
  • 最小权限原则：Agent A只能访问它被授权的数据，不能看到Agent B的数据
  • 审计追踪：每个数据操作都可以追溯到具体的Agent
  • 动态权限：Agent的权限可能随任务变化而动态调整

Supabase的Row Level Security（RLS）机制天然适合这个场景。通过在数据库层面定义策略（policy），可以确保即使Agent直接执行SQL查询，也只能看到它被授权的行。这比应用层面的权限检查更安全，因为它是在数据库引擎内部强制执行的，无法被绕过。

第六章：风险与反面论证——105亿美元估值的脆弱性

任何诚实的分析都必须正视风险。Supabase的105亿美元估值面临以下结构性挑战：

风险1：Agent经济的时间表不确定性

AI Agent的大规模生产部署仍处于早期阶段。截至2026年6月，大多数企业的Agent应用仍停留在实验和POC阶段。McKinsey在2025年的调查显示，虽然65%的企业在”实验”AI Agent，但只有不到10%将其部署到了生产环境中的关键业务流程（来源：McKinsey Global Survey on AI, 2025）。如果Agent经济的爆发比预期晚2-3年，Supabase可能面临”估值领先于收入”的困境——类似于2021年许多高估值SaaS公司在2022-2023年经历的估值回调。

风险2：大型云厂商的挤压

AWS（Aurora）、Google Cloud（AlloyDB、Cloud SQL）、Azure（Azure Database for PostgreSQL）都在提供托管Postgres服务，且都在积极集成向量搜索和AI能力。AWS在2024年底为Aurora PostgreSQL添加了pgvector支持，Google的AlloyDB也在2025年推出了AI相关的集成功能。当这些巨头决定复制Supabase的”全栈BaaS”体验时，Supabase的差异化优势可能被侵蚀。

不过，历史表明，专注的初创公司在开发者体验上通常能持续领先于大厂的”模仿产品”。AWS的Amplify试图复制Firebase的体验已经很多年了，但在开发者满意度上从未真正接近Firebase或Supabase。StackOverflow的2024年开发者调查中，Supabase的满意度评分显著高于AWS的同类产品。

风险3：开源的双刃剑

Supabase的开源策略意味着任何人都可以自托管其全部功能而不付费。对于大型企业，自托管可能是出于合规和安全考虑的首选方案。如果自托管用户的比例过高，Supabase的云服务收入转化率可能低于预期。

Redis Labs（现Redis Inc.）的经历是一个警示：它在2018-2019年被迫修改开源许可证（从BSD改为SSPL），以防止AWS等云厂商免费使用其代码提供托管服务。Supabase目前使用Apache 2.0许可证，尚未面临类似压力，但随着规模增长，这一风险不可忽视。

风险4：Postgres本身的技术局限

尽管Postgres通过扩展可以做很多事情，但它毕竟是一个40年历史的系统。在某些极端场景下（如超大规模向量搜索、超低延迟实时流处理），专用系统可能仍然有性能优势。具体而言：

  • pgvector在百万级向量规模下的查询性能，与Pinecone或Milvus等专用向量数据库相比仍有差距（根据ANN-Benchmarks的测试数据，pgvector的recall@10在高维向量上比HNSW专用实现低约5-15%）
  • Supabase Realtime在超高并发场景下的吞吐量，与Kafka或Redis Streams相比可能存在瓶颈

Supabase的”一个Postgres解决所有问题”的理念在面对极端工作负载时可能需要妥协。但对于80%的Agent用例——中等规模、多功能需求、快速迭代——这个trade-off是合理的。

我的判断

综合以上风险，我认为Supabase的105亿美元估值在18-24个月的时间窗口内是合理的，前提是：(1) AI Agent的生产部署在2026-2027年确实进入爆发期；(2) Supabase能够保持其在开发者体验上的领先地位；(3) 公司能够成功从SMB市场向企业市场上攻。

如果这三个条件都满足，105亿美元可能还是低估了。如果任何一个条件不满足，估值可能面临30-50%的回调压力。

第七章：下一代云计算的价值重新分配——当基础设施为Agent而非人类服务

让我们退后一步，思考更宏观的问题：Supabase的崛起反映了云计算价值链的什么变化？

从”服务开发者”到”服务Agent”的范式转移

过去20年，云计算的价值创造逻辑是：

  • IaaS层（AWS EC2、Azure VM）→ 为运维工程师服务
  • PaaS层（Heroku、Vercel）→ 为应用开发者服务
  • SaaS层（Salesforce、Slack）→ 为终端用户服务

现在，一个新的层正在出现：

  • Agentic Infrastructure层 → 为AI Agent服务

这个层的特征是：消费者不是人类，而是软件Agent。Agent不需要漂亮的UI，但需要极低延迟的API。Agent不需要手动配置，但需要自动化的资源编排。Agent不会打客服电话投诉，但会在毫秒级延迟增加时自动切换到竞争对手。

Supabase的定位——一个API优先、自动化优先、零配置的全栈数据平台——天然契合这个新层的需求。它不需要根本性地改变自己的产品来服务Agent，因为它从一开始就是为”程序化消费”而非”人类手动操作”设计的。

价值分配的变化

在传统云计算中，价值主要集中在IaaS层（AWS 2024年收入超过1000亿美元）和SaaS层（全球SaaS市场2025年预计超过2500亿美元，据Gartner）。PaaS层相对较薄，因为它夹在两者之间，既没有IaaS的规模经济，也没有SaaS的用户粘性。

但在Agent时代，PaaS/BaaS层可能会膨胀，因为：

  1. Agent不直接使用IaaS（它们不管理VM），所以IaaS对Agent不可见
  2. Agent不使用SaaS的UI，所以SaaS对Agent的价值降低（API才是价值载体）
  3. Agent需要的是API层面的数据服务——这正是PaaS/BaaS的定位

如果这个逻辑成立，那么像Supabase这样的”Agent-native BaaS”可能会在未来5年内占据云计算价值链中一个比历史BaaS更大的份额。这也是为什么投资者愿意给Supabase 105亿美元估值的深层原因——他们不是在按SaaS倍数估值，而是在按”下一代云计算基础设施”的逻辑估值。

对立视角：Agent是否真的需要独立数据层？

一种反对意见认为：Agent的状态管理可能会被LLM提供商自己解决。OpenAI的Assistants API已经内置了线程（Thread）和文件存储功能；Anthropic的Claude也在探索持久化记忆能力。如果LLM平台自己提供了足够好的状态管理，第三方数据层（如Supabase）的需求可能被削弱。

我对此的判断是：LLM平台提供的状态管理是”围墙花园”式的——它只在该平台的模型内有效。但企业级Agent通常需要跨模型、跨平台的数据持久化能力。一个企业可能同时使用OpenAI的GPT-4o、Anthropic的Claude和开源的Llama来驱动不同的Agent，这些Agent需要一个统一的、模型无关的数据层。Supabase作为中立的开源平台，恰好填补了这个位置。

对开发者和企业的”So What”

如果你是一个正在构建AI Agent的开发者或企业，Supabase的崛起意味着什么？

  1. 短期（6-12个月）：如果你的Agent需要持久化状态，Supabase是一个值得认真评估的选择。它的全栈能力意味着你可以减少集成的复杂度。具体建议：用Supabase的Vector功能替代独立的向量数据库，用RLS替代应用层权限检查，用Realtime替代独立的消息队列——至少在原型阶段，这能显著加速开发。

  2. 中期（1-3年）：关注Supabase是否会推出专门针对Agent的产品特性——如Agent身份管理、Agent间数据共享协议、Agent生命周期管理等。这些特性的出现将标志着”Agentic Infrastructure”从概念变为产品。

  3. 长期（3-5年）：数据库市场的格局可能会被重塑。当Agent成为数据库的主要”用户”时，数据库的评价标准将从”开发者体验”转向”Agent可编程性”。选择一个在这两方面都强的平台，是降低未来迁移成本的最佳策略。

结语

Supabase从20亿到105亿美元的估值跃迁，不是一个简单的”热门公司融了一大笔钱”的故事。它是一个更大叙事的缩影：当AI Agent成为软件系统的一等公民，基础设施的需求结构会发生根本性变化，而那些恰好卡在正确位置的公司会获得超额回报。

Postgres——这个1986年在UC Berkeley诞生的数据库系统——之所以能在2026年支撑一个105亿美元的创业公司，不是因为它本身有什么AI魔法，而是因为它的扩展性架构允许它在不改变核心的情况下适应每一代新的工作负载。从Web应用到移动应用，从数据分析到向量搜索，从服务人类开发者到服务AI Agent——Postgres的”瑞士军刀”特性在每一次范式转移中都展现出新的价值。

Supabase的赌注是：在AI Agent时代，”一个Postgres实例解决所有问题”的价值主张会比以往任何时候都更有吸引力。因为Agent不像人类开发者那样有能力和耐心去集成5个不同的服务——它们需要一个统一的、API一致的、零配置的数据平台。

105亿美元买的不是一个数据库公司。买的是一个赌注：在Agent经济中，数据层的价值会远超过去任何一个时代。而这个赌注能否兑现，取决于一个简单的问题——未来3年，你的公司会运行多少个AI Agent？

参考资料

  1. Database startup Supabase raises $500 million at $10.5 billion valuation — CNBC, 2026-06-04
  2. Supabase Raises $500M as AI Agents Spark Database Explosion — PYMNTS, 2026-06-04
  3. Supabase Raises $500M at $10.5B to Accelerate Lead in Agentic Infrastructure — PR Newswire, 2026-06-04
  4. Supabase rockets to $10.5B on $500M raise as vibe coding era dawns — TechBuzz, 2026-06-04
  5. Supabase nabs $5B valuation, four months after hitting $2B — TechCrunch, 2025-10-03
  6. Supabase Raises $100M at $5B Valuation, Co-Led by Accel and Peak XV — PR Newswire, 2025-10-03
  7. Supabase Series F — Supabase Official Blog, 2026-06-04
  8. Supabase Raises $500 Million at $10.5 Billion Valuation to Expand Postgres Platform for AI Applications — CityBiz, 2026-06-04
  9. Introducing the Model Context Protocol — Anthropic, 2024-11-25
  10. Gartner Predicts 33% of Enterprise Software Will Include Agentic AI by 2028 — Gartner, 2024-10-14
  11. Andrej Karpathy关于”Vibe Coding”的推文 — 来源: X (Twitter), 2025-02-02
  12. LangChain State of AI Agents Report — 来源: LangChain, 2025

主题分类：AI商业模式