Supabase

1.1 身份与商业模式

Supabase 由 Paul Copplestone 和 Ant Wilson 于 2020 年创立，将托管 Postgres 数据库与身份认证、数据 API、边缘函数、实时数据、存储和向量能力打包在一起。它被定位为开源开发平台，而不是单一数据库工具；用户可免费入门，项目规模扩大后再使用付费计划并承担用量费用。法律与运营口径需要精确区分：Supabase 的隐私声明将 Supabase Pte. Ltd. 列为数据控制者，Tracxn 记录显示一家活跃的新加坡实体于 2020 年 2 月 20 日注册成立，而 FundedIQ 和 10 月融资公告则将旧金山列为运营基地。这一区分会影响合同签署、治理、税务和注册地尽调。[CO001, CO002, CO003]

1.2 管理层与治理

两位创始人仍是公开可见的运营负责人：Copplestone 担任 CEO，Wilson 担任 CTO。这种延续性有助于保持产品一致性和创始人与市场的匹配，但也意味着战略和技术权力集中在两个人手中。Tracxn 的公开董事会记录只列出两位创始人为现任成员，以及一位过往独立成员；这并不是确定的股权结构或法定董事会披露。现有来源没有确认当前外部董事、观察员权利、表决门槛、创始人持股或投资人保护性条款。因此，治理文件、继任安排和保留事项权利应列为优先尽调事项，不能根据投资人声望推断。[CO002, CO004, CO005]

1.3 资本化与运营规模

Supabase 于 2026 年 6 月宣布完成 $500 million F 轮融资，投前估值为 $10 billion，约合投后 $10.5 billion。四个月后，公司公告宣布由 GIC 领投的另一笔 $150 million 融资及收购 Turso，但没有披露新估值。累计融资不能写成一个经过验证的单一数字：RevenueMemo 报告截至 6 月轮次约为 $996 million，FundedIQ 记录四轮合计 $880 million，Tracxn 则报告截至 10 月八轮合计 $1.19 billion。这些口径不可互换，而且部分融资包含员工流动性安排，因此募资额不能当作可用现金。[CO006, CO007, CO008, CO009, CO010]

1.4 增长势头、里程碑与待解指标

公司披露的开发者覆盖从 6 月的近 10m 名增至 10 月的逾 13m 名。10 月公告还称，每月新增逾 100 万用户和 400 万个数据库，其中 70% 的新数据库由代理或 AI 驱动工具创建。这些是使用指标，不是客户、收入、留存或变现指标。员工数据也互相冲突：FundedIQ 给出 101-250 人区间，Tracxn 则称截至 2026 年 8 月有 439 名员工。因此，在把使用增长或融资规模当作运营表现代理指标之前，融资尽调应取得带日期的工资、客户、ARR、毛利率、烧钱和净留存明细。[CO011, CO012, CO013, CO014, CO015, CO016]

1.5 展示项

2.1 市场边界、品类范围与支出定义

Supabase 横跨开发者后端基础设施和托管数据库市场，核心聚焦 PostgreSQL 关系型生态。主要品类包括托管数据库、开发者后端即服务（BaaS）、身份认证与管理、无服务器边缘计算、文件与对象存储、实时数据流，以及通过 pgvector 实现的向量嵌入索引。纳入的客户支出包括专用数据库计算实例、月活用户身份档位、源站及缓存带宽出口、运营存储容量，以及 SOC2、ISO 27001 和 HIPAA 认证等企业合规附加服务。相反，排除的客户支出包括前端 Web 应用托管（主要由 Vercel、Netlify 等生态伙伴主导）、全套企业数据仓库与分析型 OLAP 基础设施（如 Snowflake、Databricks），以及传统专有企业 NoSQL 数据库。Supabase 并非取代 Web 托管平台，而是位于现代应用框架旁边：在检测到的 Supabase 生产域名中，40.05% 与 Vercel 并用，说明 Supabase 更像可组合的数据层，而非一体化 PaaS 巨头。主要替代品包括 Google Firebase 等传统云 BaaS 平台、带 DynamoDB 和 Cognito 的 AWS Amplify 等超大规模云厂商原语，以及 Neon 等新兴无服务器 Postgres 厂商。[CM001, CM002, CM005, CM006, CM014]

2.2 可服务市场规模、增长阶段与规模差异

评估 Supabase 的可触达市场，需要分别看不同增长阶段，不能接受一个自上而下的总可寻址市场（TAM）数字。宏观上，全球数据库管理系统（DBMS）和云数据基础设施市场代表着 $100B+ 的总体支出品类，复合年增长率达到两位数；关系型系统仍是 80% 初创公司工程栈的标准。在这一市场中，面向开发者的后端平台、托管 Postgres 和 BaaS 解决方案构成估计 $12B 至 $18B 的可服务市场（SAM）。Supabase 的可服务可获得市场（SOM）具体锚定于自助开发者订阅（Pro 计划 $25/月）、团队协作环境（$599/月）和面向安全敏感组织的定制企业合同。独立 Web 爬虫的行业基准显示，截至 2026 年 8 月，Supabase 在 19,361 个跟踪域名覆盖的广义 PaaS 品类中占 0.83%，在 41 项受监测技术中排名第 11。然而，市场采用指标呈现明显分化：数据库创建量同比增长超过 600%，由自主编码代理和 AI 构建工具推动，后者发起的新项目超过 60%；但商业变现仍高度集中。公开域名检测和社区论坛经常显示，Supabase 只出现在微型网站、黑客松项目或子公司子域名中，而不是核心企业交易账本。把 1,000 万注册开发者直接等同于商业 ARR 的规模模型，可能严重高估真正的企业钱包捕获。[CM003, CM004, CM005, CM011, CM012, CM014]

2.3 买方画像、用户分层与采购归属

Supabase 生态中的客户分层和预算归属清晰分为三档：个人开发者与原型初创公司、成长期工程团队，以及受监管企业。入门用户通常是开发初始应用的个人开发者、业余爱好者或非技术创始人。这些用户使用较为慷慨的 Free 层（支持两个活跃项目、500 MB 数据库磁盘和最多 50,000 月活用户），看重即时 SQL API 和零前期资本支出。成长期的经济买方通常是技术创始人、CTO 或工程副总裁；当应用需要生产可靠性、每日备份和 SLA 时，他们会升级到 Pro 层（每个组织每月 $25）。此时预算通常来自部门工程团队的信用卡支出。第三类是成熟的中型公司和企业，需要组织控制、单点登录（SSO）、14 天至 90 天日志留存、SOC2/ISO 27001 合规（$599/月 Team 层的标准功能），或在定制 Enterprise 合同中加入专门的 HIPAA 协议和私有 Slack 频道。在企业环境中，采购权会从个人开发者转移至中央 IT 采购、信息安全评审委员会和财务负责人；他们会审查数据处理附录及监管保障。[CM007, CM008, CM010, CM013]

2.4 结构性增长驱动与关键采用约束

Supabase 的快速市场扩张由两股结构性顺风推动：全行业向 PostgreSQL 集中，以及 AI 辅助代码生成的爆发。2026 年，Postgres 在初创公司生态中的渗透率升至 80%，MongoDB、MySQL 和 Firebase 等传统 NoSQL 替代品则持续丢失市场份额。此外，Claude Code、Codex 等 AI 编码代理的出现从根本上加快了数据库配置：新创建的 Supabase 数据库中超过 60% 由 AI 工具自动启动。标准关系表原生支持 pgvector，让开发者无需部署独立向量数据库基础设施即可构建检索增强生成（RAG）流水线。但企业采用仍受实质性约束。首要问题是定价可预测性和超额风险：基础计划价格虽低，但项目计算实例按项目计费（$10 月度额度只能覆盖一个微型实例），高流量应用还会累积数据库存储、出口带宽（源站出口 $0.09/GB）和身份额度费用。月活达到 100,000 时，身份和计算账单可能让总成本意外波动。此外，对于已与 AWS、Google Cloud 深度绑定、拥有议价折扣和成熟 IAM 治理的大型企业，迁移成本仍然很高。[CM001, CM005, CM009, CM010, CM011]

2.5 市场尽调重点、缺口与规模不一致

严格评估 Supabase 的市场地位，会发现若干关键尽调缺口，妨碍对其长期企业渗透率做出结论。首先，年度经常性收入（ARR）、收入运行率和净收入留存（NRR）的审计数据仍属私人信息，尚未披露。尽管公司于 2026 年 6 月以 $10.5B 投后估值完成 $500M F 轮融资，但缺乏第三方审计验证时，市场对 ARR 的私人估算相差很大。其次，第三方域名爬取数据表明，虽然 Supabase 出现在 19,361 个域名中，但由于前端 JavaScript 检测波动，历史检测结果在两次爬取之间有 15% 消失；主要客户引用也经常位于非关键的社区子域名，而不是核心应用后端。第三，免费 AI 生成的爱好者项目长期转化为稳定、持续性企业合同的比例仍未被证明。尽调必须确认，自主编码代理产生的是可持续、高 ACV 的企业软件，还是免费试用期结束后就放弃付费层的短命原型。[CM003, CM004, CM008, CM012, CM014]

2.6 展示项

3.1 竞争格局与市场分层

Supabase 周边的开发者基础设施市场分为四类：按需拼装原语的超大规模云厂商、专有后端即服务平台、专注无服务器数据库的厂商，以及开源或自带云（BYOC）框架。Amazon Web Services 等超大规模云厂商主导整体云开发者工作负载，PostgreSQL 则是行业主要关系型数据库。然而，在 AWS 上搭建生产后端，需要配置 VPC 网络、安全组、IAM 策略，以及 RDS、Cognito、S3、Lambda 等分散服务，这会给早期团队带来很大的运营复杂度。Google Firebase 等专有平台上手快、移动工具成熟，却把开发者锁定在专有 NoSQL 文档存储和特殊查询模型中。相比之下，Neon 等无服务器 Postgres 产品主要聚焦数据库自动扩缩容和分支，而不打包应用层服务。Encore、Northflank 等 BYOC 框架则把基础设施部署到客户自己的云账户中，为已超出托管多租户服务能力的工程组织提供架构灵活性。[CP001, CP002, CP007]

3.2 功能能力与架构取舍

Supabase 的主要差异化来自开发者体验和统一产品打包：在一个控制台中，同时提供托管 PostgreSQL、行级安全、内置身份认证、对象存储、无服务器边缘函数和基于 WebSocket 的实时流。这种架构打包消除了通常需要将独立基础设施组件连接在一起的集成摩擦。相比 Firebase，Supabase 提供标准 PostgreSQL、完整的关系模式灵活性、高级索引和 pgvector 扩展，直接利好包含人工智能工作流的应用。不过，捆绑架构也有刻意的技术妥协。Supabase Edge Functions 在 Deno 运行时上执行，并受执行时长限制，因此不适合长时间计算任务或繁重的异步后台处理。面对复杂的异步任务编排或高并发微服务架构，开发团队往往还要补充专用计算工作节点或混合云服务。[CP003, CP004, CP008, CP012]

3.3 定价拐点与 AWS 迁移动态

Supabase 与超大规模云厂商的总拥有成本，会随用户规模和资源消耗结构而显著分化。对于月活不超过 100,000 的早期和成长期应用，Supabase 具备明显经济优势。典型的 100,000 MAU 工作负载在 Supabase 上每月约 $600 至 $650，而 AWS 上的等效按需架构每月为 $3,000 至 $3,200。这一差异主要由身份认证成本驱动：AWS Cognito 在超过 10,000 用户免费额度后按每 MAU 收取 $0.015，比 Supabase 的每 MAU $0.00325 超额费高出 4.6x。但当应用达到 1,000,000 或更多活跃用户后，经济账开始反转。在更高规模下，企业协议、可带来 30% 至 60% 折扣的预留实例计算承诺，以及精细的网络优化，能让超大规模云厂商提供更好的单位经济性。Supabase 的带宽出口费用为 $0.09/GB，纵向升级计算实例也会带来显著成本，促使高吞吐平台考虑把工作负载直接迁移到原生云环境。[CP005, CP006, CP011]

3.4 壁垒韧性、迁移成本与替代风险

Supabase 的防御力来自开源定位、开发者心智份额，以及与 Lovable、Replit、Figma 等现代 AI 应用构建工具的集成。公司以开源 PostgreSQL 为标准，提供较高的核心关系数据可移植性，团队可以导出模式并将数据转储到任何标准 Postgres 安装中，几乎不会遇到阻抗不匹配。不过，应用层仍存在有意义的迁移成本。离开 Supabase 需要重构平台专属的身份认证辅助函数、客户端 SDK 调用、行级安全规则假设和 WebSocket 订阅。此外，Supabase 在企业市场高端还面临结构性架构约束：平台依赖单写入器 PostgreSQL 计算模型，没有原生水平分片能力，需要分布式多区域写入或极端事务吞吐的工作负载最终会遇到纵向上限。再加上企业单点登录（SAML）和 HIPAA 合规被放在高阶商业协议之后，这会增加受监管企业的采用摩擦。[CP009, CP010, CP013, CP014]

3.5 展示项

4.1 收入模式与定价

Supabase 变现的是捆绑式云平台，而不是单一数据库产品。其官网介绍 Postgres 数据库、身份认证、API、边缘函数、实时能力、存储和向量能力；Sacra 则将商业模式描述为分层订阅 SaaS，并根据数据库大小、带宽和月活用户额外收费。Sacra 列出的价格为 Free、每月 $25 的 Pro 和每月 $599 的 Team，但这些只是二手来源的标价，不能证明实际合同价值、折扣或收入确认。公开资料也没有披露收入中有多少来自基础订阅、用量、企业条款或 Supabase for Platforms。这一区分很重要，因为庞大的开发者漏斗，取决于转化率、工作负载持续性和计量消费占比，可能产生完全不同的收入质量。[CI005, CI006, CI010, CI012, CI013, CI014]

4.2 增长势头与 GTM 效率代理指标

公开增长信号很强，但不能与审计收入混为一谈。Supabase 6 月称拥有逾 250,000 名客户，Supabase for Platforms 的客户数在六个月内增长了 370%。10 月公司称每月新增逾 100 万用户和 400 万个数据库，其中 70% 的新数据库由代理或 AI 驱动工具创建。CNBC 另报 6 月员工数为 350 人，Sacra 则认为编码助手分发降低了市场进入成本。这些指标合在一起说明产品驱动分发效率较高，却不是经过测量的 CAC 回收期：保留的来源没有提供付费/免费拆分、销售与市场费用、群组转化、NRR 或客户集中度。Sacra 对 5 月 ARR 的 $170 million 估算可作为方向性第三方估计，但不能替代管理层收入台账。[CI004, CI008, CI009, CI010, CI011]

4.3 成本结构与资本充足性

最明确的公开成本信号来自 Sacra：托管和存储会挤压毛利率。这一判断与托管数据库平台的方向一致，但没有量化 COGS 或利润率。2026 年，Supabase 宣布 6 月和 10 月两轮合计 $650 million 融资，包括以 $10.5 billion 投后估值完成的 $500 million F 轮，以及与收购 Turso 相关的 $150 million 10 月融资。资金用途包括产品开发和员工流动性。募资额不等于手头现金：保留的来源没有披露原始发行与老股转让分配、收购对价、当前现金、债务、月度烧钱、资本开支或已承诺的基础设施义务。这些缺口使人无法可靠计算现金跑道，也无法断定近期融资风险较低。[CI001, CI002, CI003, CI007, CI015, CI016]

4.4 投资判断与尽调阻塞项

这项投资在需求端很有吸引力，但经济性证据并不完整。订阅加用量定价可以随客户工作负载扩张，代理驱动分发也可能降低获客成本；但基础设施消耗会随同样的活动增长，且没有保留来源确认贡献毛利、留存或盈利能力。即便是融资总额，也必须谨慎解读：Multiples 报告八轮合计 $996 million，而 Supabase 6 月公告称在额外的 10 月轮次之前已超过 $1 billion。这一差异可能来自来源时间或汇总方法，但不应被悄然调和。因此，在判断可持续增长或现金跑道前，投资判断需要管理层提供 ARR 定义、GAAP 收入、按产品划分的毛利率、免费转付费转化、NRR、客户集中度、现金、烧钱、融资条款和 Turso 对价等证据。[CI004, CI006, CI007, CI008, CI014, CI015, CI016]

4.5 展示项

5.1 产品界面与客户工作流

Supabase 以一体化后端开发平台交付，而不是作为独立数据库。开发者从完整的 Postgres 数据库开始，再通过同一产品界面加入身份认证、生成式数据 API、实时同步、对象存储、边缘函数和向量搜索。客户工作流压缩了基础设施组装：团队建模关系数据、挂接行级访问策略、调用生成式 API 或客户端库，并使用相邻服务，无需为每一层分别选择和集成供应商。Supabase 当前网站和架构文档主要验证了这一广度；一篇具有商业利益关系的第三方解读也佐证了模块范围，但不是独立基准。因此，产品确实具备可信的广度优势，但达到生产环境的时间和迁移结果仍取决于具体部署。[CE001, CE002, CE003, CE004, CE005, CE006, CE007, CE010]

5.2 架构、组合与可移植性

Postgres 是事实记录系统，并未隐藏在专有数据库抽象之后。Supabase 在其周围组合成熟组件：GoTrue 负责签发身份认证令牌，PostgREST 通过 REST 暴露关系数据，Realtime 处理 WebSocket 在线状态和数据库变更流，Storage 使用 S3 兼容服务并把元数据存放在 Postgres，Deno 运行边缘函数，Supavisor 管理 Postgres 连接池。这种拆分带来两项优势：客户可以渐进式采用模块，标准 Postgres 导出路径也降低了数据锁定。它同时带来集成负担，因为交付体验依赖多个运行时、协议和发布节奏保持一致。架构文档较为完善，但已审阅的公开来源没有量化故障隔离、服务级性能或自托管完整栈的运营负担。[CE002, CE003, CE004, CE005, CE006, CE007, CE008, CE009, CE010]

5.3 部署成熟度、可靠性与规模

现有证据既显示出积极的规模化投入，也显示出尚未解决的实现风险。TechCrunch 报道，Supabase 于 2026 年 6 月推出 Multigres，用于集中处理 Postgres 扩展任务，包括只读副本、故障切换、连接限制和备份。这证明公司在响应路线图需求，但不能证明特定工作负载会达到延迟、可用性或恢复目标。一名独立自托管实践者另行询问连接限制如何与 API 流量交互，以及如何对即将到来的流量增长做压力测试，说明容量规划并不能仅从产品界面一眼看出。一篇 2023 年的历史实践评测还报告了本地与远端一致性问题及客户端事务限制。这些报告是个案，不是全量集群测量，但明确了具体尽调测试：在买方实际拓扑上开展负载、故障切换、迁移、回滚、连接池及本地到托管环境一致性测试。[CE011, CE012, CE013, CE016]

5.4 差异化、信任控制与尽调判断

Supabase 最强的技术差异化，是把一体化开发者体验与成熟的开源原语、直接 Postgres 访问结合起来。这让它比专有数据模型更具可移植性，但自托管只是转移运营责任，并没有消除责任。隐私声明显示，Supabase 主要作为客户提交的终端用户数据处理者，并采用商业上合理的物理、技术和组织保障；同一份声明也明确不保证绝对安全。这些是有用的治理表述，但不是独立控制审计。投资判断因此应要求当前审计报告、子处理者与数据驻留映射、事故和可用性历史、恢复测试结果，以及针对具体架构的性能数据。产品看起来广泛且技术上连贯，但是否适合任务关键型场景，仍应取决于工作负载级别的证明，而不能只看功能可用性或营销认证。[CE009, CE014, CE015, CE016]

5.5 展示项

6.1 自助服务核心，叠加项目级企业长尾

最清晰的独立分层信号来自 Web 技术数据集，而不是客户台账。TechnologyChecker 在 2026 年 8 月的读取中检测到 19,361 个使用 Supabase 的域名，并将其中 12,450 个匹配到公司记录。在能够解析员工数的子集中，69.4% 属于员工数为 1-10 人的组织，说明创始人、小团队和代理商开发项目构成了很长的尾部。同一数据集显示地域和垂直行业分布广泛，同时警告知名企业经常只出现在一个社区网站、门户或微型网站上。因此，潜在买方从个人开发者到部门创新负责人都有可能；终端用户可能是开发者、内部构建者或应用客户，而预算负责人无法从公开检测中观察到。[CU001, CU002, CU003, CU004, CU005, CU007]

6.2 采用信号强，但分母不可合并

从两个不同视角看，采用程度似乎很高，但不能把它们合并为一条漏斗。TechnologyChecker 的 19,361 域名读数衡量可检测的 Web 实现，并明确指出，表面上的月度增长很大一部分来自信号覆盖扩大，而非平台增长。TechCrunch 另报 Supabase 公司声称拥有近 10 million 名开发者，数据库发布量同比增长超过 600%，其中超过 60% 由 AI 工具发起。域名、匹配组织、开发者和数据库发布量代表不同人群；没有一个指标能揭示活跃付费账户、使用率、收入或留存。Vercel 的共同出现，以及 Supabase 面向代码优先的代理工具，仍说明前端平台和 AI 构建工具是重要的采用入口。[CU001, CU002, CU006, CU013, CU014, CU015]

6.3 命名客户证明生产使用，不代表客户组合质量

Supabase 首页提供了具体但由公司筛选的参考案例。页面称 Lovable 借助 Supabase 支撑数百万个 AI 生成应用，eXp Realty 让逾 2,000 名员工构建生产软件，Phoenix Energy 在零停机的情况下把关键基础设施从 MongoDB 迁出，Chatbase 则在一个由 Postgres 支撑的平台上把自身业务做到 $10 million ARR。TechCrunch 独立将 Lovable 列为选择 Supabase 的产品之一，强化了客户识别，但没有审计 Supabase 声称的规模或客户结果。这些案例展示了多样的使用场景和可信的生产意图，却没有披露合同价值、合作期限、续约行为、支持负担，或 Supabase 在每个客户技术栈和工作负载中所占的比重。[CU008, CU009, CU010, CU011, CU012]

6.4 商业持久性仍是决定性证据缺口

公开证据不足以支持留存或集中度结论。指定来源没有报告 NRR、GRR、客户数流失或收入流失、群组留存、续约率、平均合同期限、扩张收入、付费转化、获客成本，也没有报告头部客户收入占比。竞争对手撰写的比较指出，SQL 专业能力要求、配置、调试、扩展成本和工作负载适配确实会造成采用摩擦；但这些来源带有商业利益，无法量化实际流失。因此，投资判断应将广泛采用和知名客户案例视为漏斗上游信号及生产使用证明，而非持久变现的证据。要补上这一缺口，需要私有群组明细、客户级收入集中度、续约数据，以及覆盖自助、Team 和 Enterprise 客户的参考访谈。[CU016]

6.5 展示项

7.1 风险态势与论点失效条件

风险分布不对称：强劲的开发者采用和熟悉的 Postgres 核心降低了产品采用风险，但 AI 辅助快速创建项目，也扩大了可能错误配置访问控制的缺乏经验的运营者群体。因此，最有决策价值的监测指标不是数据库发布量，而是暴露项目的数量和严重程度、通知客户并完成修复所需时间，以及更安全的默认设置能否减少重复事故。如果重大暴露持续存在且没有可衡量的下降、主数据库瓶颈反复造成生产故障，或商业转化和持久工作负载无法支撑 2026 年 6 月融资所隐含的预期，就应暂停这一论点。该矩阵是定性优先级排序，不是经过测量的概率模型。[CR001, CR002, CR011, CR013, CR014]

7.2 安全、隐私与法律风险

UpGuard 报告的暴露发现，证明生态层面确实存在一种故障模式，但不能证明 Supabase 自身遭到入侵，也不能证明所有受影响项目都有同一根因。Supabase 表示项目默认安全，并将配置责任交给客户；但托管应用暴露个人数据时，这种责任划分并不能消除声誉、支持或监管层面的外溢影响。隐私声明区分了 Supabase 对账户数据的控制者角色和对客户数据的处理者角色，并说明了国际传输与子处理者。尽调应取得暴露检测方法、受影响项目分母、事故时间线、默认政策变化、通知服务水平、DPA 与 SCC 文件包，以及当前独立保障报告，再判断法律和控制成熟度是否得到充分验证。[CR001, CR002, CR003, CR004, CR005, CR006, CR007, CR015]

7.3 运营韧性与产品执行

托管 Supabase 减少了基础设施组装工作，但没有消除数据库工程。独立分析称，典型项目以一个主 Postgres 数据库为中心：副本负责分发读取，而写入仍汇聚到主库。截至 2026 年 9 月，Multigres 被描述为 alpha 版本且尚未达到生产就绪，因此不应把它当作当前水平写入扩展方案来进行投资判断。评测还指出 Edge Function 冷启动需要 200-400 毫秒、缺少原生分析、队列和高级缓存，并且即时支持渠道有限。这些是取决于工作负载的约束，并非普遍缺陷。经过确认的恢复测试、客户专属 RPO/RTO 证据、饱和阈值、升级响应时间和生产版 Multigres 路线图，才是适当的投资判断证据。[CR003, CR008, CR009, CR010, CR011, CR012]

7.4 伙伴、财务与模式依赖

Supabase 的隐私披露列出一条广泛的运营链，涵盖云、边缘、支付、通信、分析和 AI 供应商。这份名单证明依赖面很广，但不代表支出集中度、合同替代权、相关故障暴露或恢复时间。该模式还依赖把开源和 AI 生成的采用转化为持续付费工作负载。TechCrunch 报告 Supabase 以 $10 billion 投前估值完成 $500 million F 轮，TechCrunch 和 Nexuswild 也重复了公司披露的数据库活动加速。募资额不是可用现金，发布量增长不是收入，而公开证据没有披露经审计的单位经济性。投资尽调应要求供应商集中度、SLA 和退出计划数据，以及群组转化、留存、毛利率、烧钱和工作负载质量指标。[CR013, CR014, CR016]

8.1 投资建议与价格纪律

建议为持续跟踪 / 继续研究，信心中低，估值风险高。正面情形是异常强劲的采用势头：公司材料披露客户超过 250,000，独立报道显示数据库发布量同比增长超过 600%，开发者接近 10m 名。产品覆盖数据库、身份认证、存储、边缘函数、实时能力和向量能力，同时保持开源定位。制约因素是价格。由于 10 月融资没有公布新价格，2026 年 6 月的价格仍是最近明确的估值锚点；但当前收入没有披露，指定的公开记录中也没有审计 ARR、留存、利润率、烧钱或现金证据。因此，入场应以私有运营证据和条款为前提，不能只依据表面使用量指标。[CV001, CV007, CV008, CV009, CV011, CV014, CV016]

8.2 融资背景与资本结构悬置

6 月轮次被报道为 $500 million，投前 $10 billion、投后 $10.5 billion，此前是按 $5 billion 估值完成的 $100 million E 轮。10 月，Supabase 披露在收购 Turso 的同时又融资 $150 million，但收购对价和 10 月估值均未披露。最近一轮还包含员工流动性安排，却没有量化原始发行与老股转让的拆分，因此募资额不能视为可用现金。Forge 列示所展示 F 轮类别的 1.0x、非参与型清算优先权，但完整股权结构表、全部优先级层次、期权稀释、老股转让和收购对价仍需一手尽调。不同供应商和轮次口径给出的公开总额也不一致，因此股权结构表，而非聚合平台总额，才是应当依赖的事实来源。[CV001, CV002, CV003, CV004, CV005, CV006, CV010, CV013]

8.3 情景框架与可比纪律

情景区间使用披露的 $5 billion 和 $10.5 billion 私募融资价格作为决策锚点，而不是内在价值估算。在支持最新价格以上的任何价值之前，乐观情景需要经审计的付费转化、持久的企业留存、有吸引力的毛利率和可信的流动性路径。基准情景是运营持续进展，但公开经济性证据不足，因此更适合等待或谈判显著更好的保护条款。悲观情景包括转化疲软、支持或基础设施成本跑赢收入、估值倍数压缩或收购整合风险，估值可能回落到早先的 $5 billion 以下。由于当前收入和 Turso 对价均未披露，基于指定证据无法合理支持收入倍数、上市公司倍数或并购倍数。[CV001, CV005, CV008, CV010, CV011, CV015, CV016]

8.4 退出准备、尽调要求与论点失效触发器

融资渠道很强，但退出准备度尚未得到证明。Forge 将市场活动标为有限，没有可用的 Forge 价格；证据中也没有 IPO 申报文件、经审计的公开财务报表或可靠的二级市场成交价。投资前，尽调应核对完全摊薄股权结构表、原始发行与老股转让所得、所有清算优先权、ARR 与已确认收入、群组留存、按工作负载划分的毛利率、云和支持成本、烧钱与现金、客户集中度，以及 Turso 购买和整合条款。论点失效触发器包括降价轮、付费转化或留存明显恶化、毛利率持续受压、收购整合失败，或数据库创建增长没有转化为留存的付费工作负载。经验证的流动性路径或足够受保护的入场价格，可能改善这一建议。[CV005, CV006, CV011, CV012, CV013, CV015, CV016]

8.5 展示项