前两天，BaaS 圈发生了一件足以让所有「后端托管党」心里一沉的事：8 月 19 日，被开发者社区称为「AI 时代 Firebase」的创业公司 Instant 在官网发布告别信——整个团队正式加入 OpenAI。Instant 官网而它刚在一周前发布了 1.0 版本，新用户注册当天关闭，云托管服务进入明确的关停倒计时：2027 年 8 月 31 日。36氪
看完新闻的第一反应可能是：还有一年缓冲，好像还行？但把告别信读完你会发现，这大概是 BaaS 史上「最体面的一场葬礼」——今年 7 月 31 日之后的订阅全额退款、官方写好自托管迁移指南、数据备份再保留一年到 2028 年。Instant 官网可体面的葬礼也是葬礼：团队的心思已经走了，产品不会再独立演进，平台上的 1.7 万用户、40 万个应用，只能在迁移和自托管之间二选一。
Instant 是什么来头
不关注这家公司的朋友，先把数据摆出来：Instant 是 YC S22 的项目，2024 年完成 340 万美元种子轮融资，投资名单相当能打——前 Firebase CEO James Tamplin、YC 联合创始人 Paul Graham、OpenAI 联合创始人 Greg Brockman、前谷歌首席科学家 Jeff Dean。36氪
它做的事情，是给 AI Agent 提供一站式后端：数据库、权限验证、实时同步、离线缓存，全部开箱即用。产品形态几乎就是 Firebase 的翻版，硬核开发者圈直接给了它一个更直白的名字：「AI 时代的 Firebase」。36氪这个野心其实早就写在明面上——2022 年团队就发过一篇叫《A Graph-Based Firebase》的文章，明说要做一个图结构的「Firebase 继任者」。Instant 官网
官方告别信里的数据是：超过 17,000 名用户使用过 Instant，平台上构建了 40 万个应用，累计处理交易约 25 亿笔，GitHub 星标如今是 10.5k。Instant 官网这不是玩具项目，是在生产环境里反复验证过的工业级基建。
这里有个细节特别值得玩味：2024 年那轮种子投资，下注的人里就有前 Firebase CEO。Firebase 的人投了「下一个 Firebase」，结局是被 OpenAI 整队收编、云服务进入关停倒计时。这个剧本，放在任何一家 BaaS 平台的用户身上，都笑不出来。
OpenAI 为什么买它
OpenAI 不缺会写数据库的工程师，它买的是 Agent 的「记忆层」。
现在的 AI Agent 有两个致命伤：失忆症（没有外部记忆，跨会话状态无法持久）和并发综合征（多个 Agent 同时写同一条数据，后端直接崩）。当 Agent 从「陪你聊天」进化到「替你干活」——订日程、提代码、跟其他 Agent 协调——持久状态管理和实时数据一致性就成了硬门槛。
Instant 团队过去四年死磕的就是这个脏活：实时同步、冲突解决（CRDT 算法）、离线优先。OpenAI 收下它，是给 Codex、GPT 原生 Agent 和未来的长周期 AI 工作流补上状态层。
把视野拉宽，Instant 只是 OpenAI 2026 年扫货清单上的一格：从 A/B 测试平台 Statsig 到 Python 工具链 Astral，它买的全是开发者基础设施，没有一家是模型公司。36氪OpenAI 正在一块一块拼出「AI 时代平台」的底盘。
这件事为什么和 Firebase 用户有关
先说清楚：Google 不会砍掉 Firebase。它 2014 年被 Google 收购，如今是无数出海应用的默认后端，Google 还在持续给它加 AI 能力——去年 Google I/O 推出的 Firebase Studio AI 开发环境，国内就有不少人在用免费额度做 vibe coding。
但 Instant 的结局提醒的，从来不是「服务会不会明天关停」这一种风险。调价、改条款、区域访问、被收购重组，都是平台风险。关于这一点，Firebase 的中文用户社区里有的是真实体感。翻了小红书、知乎上的相关讨论，大家的使用场景和焦虑点高度集中：
第一类是出海独立开发者，最典型。小红书上「出海 App 程序开发｜用 Firebase 太香了！」这类笔记至今还在被收藏：serverless、开发快、海外访问体验稳。小红书一个人用几行代码搞定登录、数据库、推送、托管，确实香。
第二类是 AI 编程玩家。Firebase Studio 上线后，小红书上「免费的平替 Cursor 来了」拿到了 300 多赞、270 多收藏——零成本云开发环境加 AI 生成，很多人的第一个网页应用就是这么出生的。小红书
第三类是被账单伤过的人。有小红书用户吐槽「避雷 firebase，用了半年突然无法支付账单，邮件联系官方四五天没人回，好怕突然把我整个应用删掉」。小红书今年 3 月还有个更骇人的案例：一个三人创业团队 Gemini API 密钥被盗，48 小时被刷出 8 万多美元账单——他们每月原本的云费用只有约 180 美元，Google 拒赔。36氪36氪那是 Gemini 的事故，但 Firebase 的 Blaze 计费走的也是同一套 Google Cloud 账单体系，这把剑同样悬在 Firebase 用户头上。
摆在明面上的三条出口
Instant 事件把一个一直存在、但总被「方便」盖过去的问题摆上了桌面：选 BaaS，第一天就该想好出口。眼下市场里明明白白摆着三条路。
出口一：留在 Firebase，把备份做扎实。 适合已经在 Firebase 上跑着的项目，尤其是出海小产品。Firebase 的成熟度、海外节点覆盖、与 Google 生态的联动仍是三者里最强的，没必要因为一条新闻慌忙迁移。但三件事要提上日程：Firestore 数据定期导出、Auth 用户列表保留导出能力、Storage 文件保持同步习惯。数据是你的，平台只是旅馆。
出口二：迁往 Supabase。 适合新项目，或对锁定特别敏感的用户。Supabase 是当下声量最大的「开源 Firebase 替代」：6 月它 GitHub 星标突破 10 万的消息在知乎刷屏。知乎8 月下旬知乎专栏转发其 CEO 访谈，提到它的估值已突破 100 亿美元、全员远程办公。知乎国内侧，火山引擎 7 月底也上线了 Supabase 相关的 AI Gateway 能力。知乎它底层是 Postgres，关系型、数据模型通用，「搬走」天然比 Firebase 的 NoSQL 文档模型容易——看一眼 Supabase 的表结构编辑器，数据和关联一目了然。
但也要泼盆冷水：迁移不是搬数据。Firestore 的文档结构要重新建模成 Postgres 表，Auth 体系要重新接入，而 Firebase 最强的实时同步与离线体验，Supabase 的完成度值得先实测再押注。存量项目半途切换，迁移人力要认真算账。
出口三：一开始就选开源自托管。 适合有运维能力、把数据主权当红线的团队。Instant 的结局其实留了最后一个善意：团队加入 OpenAI 后，GitHub 开源仓库还在，官方自托管指南也摆了出来，云服务用户可以拿着代码自托管，备份窗口一路留到 2028 年 8 月。Instant 官网Supabase 同样支持完整自托管。这条路走得最稳，代价是运维自己扛。
不同人群，直接对号入座
玩票项目、原型验证：哪个顺手用哪个，Firebase 免费额度够用，唯一要做的是养成定期导出的习惯。
已在 Firebase 上的出海小产品：不迁移，做备份，盯价格变化。
新项目、想长期经营：把 Supabase 放进第一天的对比清单，实测实时和离线能力再定。
纯国内应用：Firebase 本就不合适（国内网络环境摆在那里），看国内云开发或自建。
做 AI Agent 应用的：密切关注 OpenAI 接下来把 Instant 的技术落到哪个产品里，那可能决定两年后 Agent 后端的形态。
具体怎么对比？没有巧招：把 Supabase 官网的功能清单拿出来，和你的 Firebase 用量逐项对齐——数据库、认证、存储、实时、边缘函数、向量——看看哪些不能没有，哪些可以绕，答案就差不多了。
值得盯的观察信号
Instant 的 GitHub 开源仓库动态：云服务关停日到来时，这是存量用户的救生艇。
Supabase 的定价与国内合作动向：开源替代别走「用户多了开始收割」的老路。
Firebase 免费额度与 Blaze 计费的变化：任何风吹草动，都是压在免费额度上的百万小应用的预警信号。
OpenAI Agent 产品的后续发布：Instant 的同步技术会不会开放给第三方开发者。
BaaS 是个好东西，它让一个人能干一个后端团队的活。但「几行代码写完后台」的便利，反面就是把应用的出口钥匙也交了出去。Instant 的 1.7 万用户，只是替我们把这行剧本先演了一遍——而且这次的告别还算体面。下一次，未必还有 12 个月的退款窗口。
如果你的应用后端也托管在别人的云上，今晚可能是个适合导出数据的好时机。
