2026 年 Supabase 替代方案：七款后端怎么选，迁移要做什么？

选择 Supabase 替代方案，先要明确你想替换什么：需要完整后端，并保留自托管选项，可以看 Appwrite；希望保留 Postgres，优先考虑 Neon；围绕实时文档数据开发移动应用，则可以看 Firebase。这七种方案覆盖的技术栈范围各不相同。如果 Supabase 的数据库、登录系统和访问规则已经适合你的应用，继续使用也完全合理。

本文已于 2026 年 11 月 14 日对照各厂商定价页面和文档核验。 对比依据是公开文档，并非上手实测或性能排名。

Supabase 替代方案速览

比较费用之前，先划清替换范围。托管数据库可以替换数据表的存放位置；后端平台还提供应用用于用户登录、文件存储和服务端代码执行的服务。

CU-hour 是 Neon 的数据库计算计量单位，该单价不代表完整月账单。同样，Firebase 和 Amplify 也没有一个覆盖所有后端资源的统一订阅价。各节定价说明中的链接，是这些起步方案的来源。

各方案能替换哪些部分？

下表将相关能力合并展示，方便整体比较。“存储”指文件或对象存储，并非数据库磁盘。“自托管”指自行运行后端，而不只是把前端部署到别处。

其中比较出人意料的是 Neon。它目前的产品已包含身份验证、对象存储和函数，实时能力则处于 beta 阶段。再将它概括为“只有数据库，没有身份验证或存储”，已经不符合当前产品实际。

先确定你要哪一种后端架构

如果应用的核心价值已建立在 SQL 之上，就优先保留 Postgres。 PostgreSQL 通常简称 Postgres，是 Supabase 底层的关系型数据库：它用表保存有关联的记录，并支持跨表查询。如果客户、发票和权限已经在这套模型中正常运作，保留它可以避免不必要的重写。

因此，准备迁移发票应用的创始人，应先评估保留 Postgres 的方案，再考虑新文档数据库。关键在于目标平台能否执行业务依赖的查询和访问规则，而不是控制台看起来是否更简单。

如果问题出在集成服务，就按完整后端来评估替换。 需要更换登录系统、文件 API、函数运行时和运维方式时，应把这套服务当作一个整体审视。Appwrite 和 Nhost 值得重点考虑；Neon 扩展后的服务也应纳入评估。

只有明确的应用收益，才值得更换数据模型。 Firebase 的文档同步、Convex 的响应式编程模型，以及 PocketBase 轻量的自托管形态，都是考虑重写的理由。只是觉得账单不满意，却不知道费用来自哪种资源，不足以支撑迁移。

如果这些服务名称仍容易混淆，可以先看 Supabase 架构概览，了解数据、身份、文件和应用逻辑分别由哪部分负责。

七种替代方案，以及各自的迁移工作

1. Appwrite：完整后端的优先候选

Appwrite 覆盖 Supabase 广泛的服务组合：身份验证、数据库、文件存储、函数和实时能力。如果你希望把这些服务集中在一起，并能真正选择托管云或自有基础设施，它值得最先评估。

对开发客户门户的创始人来说，吸引力很直接：登录、客户记录、上传文档和服务端操作都能放在同一平台中。这比单独购买数据库托管，更接近购买 Supabase 时获得的服务范围。

它的数据库方案需要仔细区分。当前默认的无服务器选项是 TablesDB，专用数据库选项则包括 PostgreSQL、MySQL 和文档数据库。不能因为选择了 PostgreSQL，就假定 Supabase 客户端调用、存储权限或身份验证集成可以直接迁移。数据库引擎兼容性和应用 API 兼容性，需要分别验证。

Appwrite 是开源软件，支持通过 Docker 或 Kubernetes 自托管。它的自托管指南 明确说明，维护和扩容由你负责。重视控制权时，这个选项很有价值，但它并不承诺自行运行会更便宜。

不再选择它的理由： 你希望直接沿用现有 Postgres 架构，而把应用改接到 Appwrite 服务接口，带来的工作比解决的问题还多。Free 云端套餐达到资源上限时会冻结项目；原型阶段的免费额度，不应未经评估就成为生产环境的前提。

最适合： 需要完整后端组合，并希望保留自托管路线的创始人。
突出优势： 托管和自行运维两种部署方式下，都有广泛的服务覆盖。
定价： Pro 起价 $25/月，详见 Appwrite 定价页面。
免费试用： 提供 Free 云端套餐，并非只有限时试用。

迁移前如何评估 Appwrite？

1. 1

   选择有代表性的用户流程

   以客户登录、读取自己的记录、上传私有文档为例。它比公开待办列表更能覆盖真实后端能力。

2. 2

   梳理每项依赖

   列出这条流程用到的数据库查询、身份校验、存储权限和服务端操作，确定分别由哪项 Appwrite 服务接替。

3. 3

   在隔离环境中验证

   使用复制的非敏感记录和测试账户，确认账户能访问自己的文档，也无法访问其他客户的文档。

4. 4

   确定运维负责人

   先明确备份、升级和故障响应由谁负责，再选择云托管或自托管，最后判断迁移是否解决了最初的问题。

2. Neon：以 Postgres 为先，后端服务也已扩展

如果你希望保留 Postgres，同时重新选择周边服务，Neon 是本文中最值得优先考察的方案。数据库分支可以创建独立数据库环境，让开发者测试 schema 变更时，不必拿生产环境试错。

例如，一个业务逻辑已由服务端承载的 SaaS 应用，可能只需要更换数据库托管商，而无需同时更换登录提供商或文件服务。控制迁移范围，有助于让项目保持清晰可控。

Neon 现在也能承担更广的职责。其后端产品更新 列出了 Managed Better Auth、函数和兼容 S3 的对象存储；这些服务可以随数据库一起创建分支。实时能力目前处于 beta 阶段。如果产品依赖实时协作，应先评估这一状态，再决定是否因此切换。

数据库核心可在厂商的开源仓库 中获取。但这不等于拿到一个开箱即用、可自托管的完整云端后端替代品。选择 Neon 应看重其托管服务，不能因为有代码仓库，就认为每项功能都有轻松退出的路线。

不再选择它的理由： 应用依赖紧密集成的服务行为，迁移后仍需适配；或者你需要成熟的实时能力，而相应路径还处于 beta。保留 SQL 能减少数据库重写，却不能免除服务迁移。

最适合： 现有 Postgres 应用，以及需要独立数据库环境的开发者。
突出优势： 分支能力已从数据表扩展到关联的后端服务。
定价： Launch 按量计费，计算资源为每 CU-hour $0.106，其他资源另行收费，详见 Neon 定价页面。
免费试用： 提供 Free 套餐。

3. Firebase：为移动端文档工作流而选

Firebase 适合核心体验依赖实时数据和离线使用的应用，尤其是移动应用。其 Cloud Firestore 数据库按集合存储文档，支持实时监听器和离线操作，具体见 Firestore 文档。

设想一个现场服务应用，工作人员需要在网络时断时续的环境中更新任务记录。这是研究 Firestore 客户端行为的具体理由。相比之下，只因为两个平台都有登录功能，就迁走一套成熟的发票数据库，理由并不充分。

Firebase 通过 Authentication、Firestore、Cloud Storage 和 Cloud Functions，可以承担主要后端职责。它是专有的托管后端，并不是可以搬到自己服务器上的生产技术栈。标准 Firestore 路线也会改变数据的组织和查询方式。

这里有个重要前提：Firebase 现在也列出了由 Cloud SQL for PostgreSQL 支持的 SQL Connect。因此，说“Firebase 没有 SQL 选项”已经过于笼统。应把它当成独立架构评估，不要假定 Firestore 的文档语义和 SQL Connect 可以互换。

不再选择它的理由： 应用的关系查询需求超出所选文档模型的适用范围，或者你希望独立托管，并让用量与费用的关系更简单。从 Supabase 迁到 Firestore，需要转换查询和访问规则，而不是恢复一份 Postgres 转储文件。

最适合： 能从 Firestore 实时及离线文档行为中获益的移动和 Web 应用。
突出优势： 面向客户端的文档同步。
定价： Blaze 按量付费，Firebase 定价页面 未列出统一的固定月度订阅价。
免费试用： Spark 是免费套餐，但当前套餐对照表显示，Cloud Storage 和 Cloud Functions 需要 Blaze。

若想深入比较这两种架构，可阅读 Supabase 与 Firebase 对比。

4. Nhost：保留 Postgres，并明确选择 GraphQL

如果你想要以 GraphQL 为核心 API 的 Postgres 后端，Nhost 很适合。GraphQL 是一种查询语言，允许客户端请求特定字段及关联记录。Nhost 将 Postgres、Hasura 的 GraphQL API、身份验证、存储和无服务器函数组合在一起。

如果客户门户需要同时展示账户、所属项目和最新动态，这种 API 形态可能很适合前端。迁移理由应是你希望采用这种应用接口，而不是认为所有 Postgres 平台行为都一样。

Nhost 的源代码仓库 介绍了开源技术栈，并提供 Docker Compose 自托管示例。文档还介绍了跟踪数据库迁移和 Hasura 元数据的本地开发方式。元数据很重要：API 配置和权限，与数据库 schema 一样，都是应用的一部分。

不再选择它的理由： 你不想维护 GraphQL 和 Hasura 配置层。如果服务端已经提供产品所需的端点，新增 API 层可能只是增加职责，却没有解决客户问题。

保留 Postgres，让数据有一个熟悉的落点。但这不会自动把 Supabase 行级策略转成 Nhost 基于角色的 API 授权。两者应设为独立的验收项。

最适合： 明确希望采用 Postgres 加 GraphQL 优先后端的团队。
突出优势： 围绕 Postgres 集成 GraphQL 订阅、身份和文件存储。
定价： Pro 起价 $25/月，Nhost 定价页面 提供组织级套餐。
免费试用： Starter 免费；不活跃项目会暂停。

5. Convex：为响应式编程模型而选

Convex 用响应式后端承接数据库访问和服务端应用逻辑，应用通过 JavaScript 或 TypeScript 函数工作。它还提供身份验证、文件存储和定时任务。

协作规划应用就是合适的候选：多人更新共享工作，界面需要及时反映状态变化。选择 Convex，应是因为你想围绕这种行为开发，而不是期待把现有 SQL 应用原样搬过去。

数据库文档 做了一个有用的区分：Convex 存储类 JSON 文档，同时支持关系建模。它不是 Postgres，但说它无法表达关系也不对。数据读写通过函数 API 完成，而非 SQL。

Convex 支持自托管。后端许可文档 说明，其 fair-source 许可限制竞争性托管服务，并会在未来转为 Apache 许可。因此，不能不加限定地把它归为“开源”。

不再选择它的理由： SQL 兼容性及 Postgres 周边工具，变得比响应式应用模型更重要。自托管能改变 Convex 的运行位置，却不能把它的查询变成 SQL。

最适合： 为新应用或明确计划重写的应用选择响应式后端的开发者。
突出优势： 在同一编程模型中处理数据函数和响应式应用行为。
定价： Convex 定价页面 显示，Starter 为 $0/月起，另计用量。
免费试用： 提供 Free 套餐。

6. PocketBase：轻量自托管，但需看清生产使用限制

PocketBase 将数据库、身份验证、实时订阅、文件存储和管理界面打包成一个轻量自托管后端。它使用嵌入式 SQLite，因此与托管 Postgres 或多项云服务组合都不同。

对于内部设备台账或规模不大的社区工具，单个后端可执行文件的运维方式可能很有吸引力。但仍需有人负责部署、备份、监控和升级。“一个文件”描述的是打包方式，并不意味着运维工作消失了。

厂商的入门介绍 明确表示，PocketBase 仍在积极开发中，尚不保证完全向后兼容，除非你接受手动迁移工作，否则不建议用于生产关键应用。这条提醒比推测性的规模对比更重要。

PocketBase 是开源、自托管的软件。它能替换多项面向用户的后端能力，但不是托管套餐，也不能直接接收 Supabase Postgres 恢复。SQLite 数据模型和应用 API 都需要单独的迁移工作。

不再选择它的理由： 应用的重要性提升，需要的运维保障超出你愿意承担的范围，或者升级责任不再适合这个项目。

最适合： 所有者明确接受自托管维护责任的小型应用。
突出优势： 在紧凑的独立应用中提供数据库、身份验证、文件和实时能力。
定价： 厂商提供免费软件，未列出付费托管套餐；基础设施另计。
免费试用： 使用软件无需托管试用。

7. AWS Amplify：适合已在 AWS 上运维的团队

AWS Amplify 适合希望基于 AWS 服务构建后端，并愿意管理相关服务边界的团队。其标准数据链路使用 Amazon DynamoDB，配合 AWS AppSync API 和实时订阅。

对于已经在 AWS 账户中运营业务的公司，这可能很实用：身份使用 Amazon Cognito，文件使用 Amazon S3，自定义后端逻辑可用 AWS Lambda。但对第一次选后端的独立创始人来说，这些服务边界也意味着，出故障时需要理解更多概念。

Amplify 的数据配置指南 展示了如何通过 TypeScript 模型定义创建数据库和 API 资源。这套脚手架能提高效率，但迁移 Supabase 时，仍需将 SQL 数据、权限和函数映射到所选 AWS 服务。

JavaScript 库 是开源的，但它们连接的 AWS 托管服务，并不是可迁移的自托管后端。在自己的 AWS 账户中部署，意味着你拥有这套云配置的控制权，并不意味着独立于 AWS。

不再选择它的理由： 应用需求较简单，协调多项 AWS 服务，比使用集成更紧密的后端组合带来更多运维工作。

最适合： 已具备 AWS 应用运维能力的团队。
突出优势： 用代码定义接入 AWS 身份、数据、存储和函数的路径。
定价： 后端用量无最低月费；底层服务按实际用量收费，详见 Amplify 定价页面。
免费试用： 能否使用 AWS Free Tier，取决于具体服务和账户资格。

新评估应从当前的 Amplify 文档 开始，并确认参考教程描述的是同一种配置方式。

到底该选哪种 Supabase 替代方案？

需要完整后端组合，选 Appwrite。 针对这一需求，它兼具服务广度和明确的自托管路线，因此排在本文首位。如果保留 Postgres 和采用 GraphQL 更重要，推荐则转向 Nhost。

保留 Postgres 是首要约束，选 Neon。 先从数据库迁移开始，再决定要采用哪些额外服务。不要仅因为同一家厂商也提供身份服务，就把可控的数据库迁移扩大成身份系统重写。

只有应用行为值得重写时，才选 Firebase 或 Convex。 Firebase 的 Firestore 路线适合实时文档和离线客户端；Convex 适合响应式数据函数模型。无论哪种，验证最难的用户流程，都比先迁最简单的数据表更有价值。

主动追求简单可选 PocketBase，已投入 AWS 则可选 Amplify。 两者都不是通用兜底方案。PocketBase 将责任交给运维者，Amplify 则将责任分散在多项 AWS 服务中。

如果向量搜索需求超出 pgvector，可将 Pinecone 作为独立检索层评估，而不是把它当成 Supabase 后端的替代品。

什么时候继续使用 Supabase 更合适？

如果 SQL 模型、登录流程和行级安全已经适合产品，而候选替代方案只是重复实现它们，没有实质收益，就应考虑留下。行级安全，也称 RLS，是数据库层的规则系统，可让每个客户只能看到自己的记录。

一个正常运行的客户门户，不会因为记录换了个控制台就自动变好。有价值的迁移，应解决一个说得清的问题：所需的客户端行为、运维要求、服务限制，或有据可查的成本问题。

Supabase 定价该怎么看？

先分清担忧来自套餐、计算资源、文件、流量，还是其他资源。完整的购买分析可见 Supabase 定价详解。比较时，应包含迁移后应用仍然需要的服务，也包括仅迁数据库时会留下的部分。

Supabase 存储费用该怎么看？

如果问题在上传文件，更换数据库引擎可能根本碰不到真正的问题。选择整套新后端之前，先盘点存了什么、用户如何下载。仅更换存储应作为独立项目处理，并将文件访问规则和应用 URL 纳入范围。

哪些能从 Supabase 迁走，哪些需要重建？

Postgres 数据具有可迁移性，但能运行的应用远不止数据行。 Supabase 的备份与恢复指南 介绍了角色、schema 和数据的逻辑备份与恢复，并将存储对象和 Edge Functions 列为独立迁移工作。

如果目标也是 Postgres，从数据库入手很合理。但在认定恢复即可完成之前，应检查支持的扩展、版本和应用特有依赖。迁往 Firestore、Convex 或 SQLite，则应预期需要数据转换和查询重写。

身份验证需要独立的身份迁移方案。 Supabase 的自托管恢复指南 表示，用户记录可以包含在数据库转储中，但 JWT 密钥、提供商设置和重定向 URL 需要另行配置。按文档迁往新的自托管实例时，现有令牌会失效，用户需要重新登录。

这份指南讨论的是 Supabase 到 Supabase 的恢复，并不保证其他厂商能导入全部账户或保留全部会话。跨厂商迁移时，应在安排切换之前，先明确账户、身份标识符和登录方式如何映射。

RLS 可以导出，但实际含义取决于周边身份系统。 策略是 Postgres 对象，并非天生不可迁移的代码。不过，Supabase 的 RLS 文档 使用了 auth.uid() 和 auth.jwt() 等辅助函数。目标平台必须提供合适的身份上下文，否则就要适配策略。SQL 导入成功，不等于客户之间的隔离仍然有效。

Edge Functions 需要检查运行时和集成。 Supabase 的 Edge Functions 指南 将其描述为在兼容 Deno 的运行时上执行的可迁移 TypeScript 函数。迁移工作包括部署、密钥、网关身份验证，以及对 Supabase 服务的回调。若目标运行时不兼容，还可能需要修改代码。

迁移生产环境前，应在隔离环境中验证完整流程：登录、读取有权查看的记录、拒绝越权访问、上传并取回私有文件，以及执行关键业务操作。在目标环境中验证这些行为之前，应保留回滚路径。

这些方案如何筛选？

本文比较使用了选题中的七个候选方案，以及于 2026 年 11 月 14 日核查的官方产品页面。筛选标准包括替换范围、数据库延续性、身份和文件支持、实时行为、托管控制权、付费起步方案，以及迁移责任。

本文未进行登录后的试用、吞吐量测试或延迟基准测试。推荐是基于文档能力做出的架构判断。关键在于某个方案能否用更少的整体应用工作量解决你的需求，而不是首页列出了多少功能标签。

通用托管商不作为额外后端替代方案列入：租一台服务器，本身不能替换身份验证、文件权限或应用 API。数据库服务之所以被纳入，是因为它能提供有用的迁移目的地，同时本文也明确列出了剩余的服务迁移工作。

哪些选择应该避开？

无法承担维护，就不要把生产关键应用迁到 PocketBase。 厂商的提醒应成为选型标准，而不是一条可以轻轻带过的脚注。

没有人负责 AWS 服务配置，就不要选 Amplify。 自动生成的起点，不能免除理解底层资源的责任。

不要仅为搬迁现有 SQL，就选 Firebase 的 Firestore 路线或 Convex。 两者的编程模型都有值得采用的理由，但都不会让 SQL 重写凭空消失。

不要把 Neon 扩展后的后端服务，视为必然兼容 Supabase。 逐项验证将要替换的服务，尤其当应用必须依赖仍处于 beta 的实时能力时。

也不要只为追逐免费额度，就切换一个运作正常的 Supabase 应用。先证明替代方案带来的收益，足以覆盖迁移和持续运维的代价。

常见问题

Supabase 到底好不好用？

如果你需要 Postgres，以及集成的身份验证、文件和服务端函数，Supabase 很合适。如果应用或运维要求需要另一种模型，它就未必合适。已有的 SQL 和访问策略，都是切换前先评估是否留下的理由。

MongoDB 有哪些不错的替代方案？

这与替换 Supabase 是不同的比较。如果目标是面向文档的应用数据，可以考察 Firestore 或 Convex；如果目标是迁向关系型 SQL，可以考察 Postgres 方案。无论哪种，都不意味着能自动兼容现有 MongoDB 应用。

Supabase 可以免费用吗？

可以。当前 Supabase 套餐页面 包含有资源额度限制的 Free 层。是否适合你的应用，取决于所需服务和用量；免费可用不等于生产容量无限。

Supabase 和 Firebase 是一回事吗？

不是。两者都覆盖常见后端需求，但 Supabase 以 Postgres 为核心。Firebase 的 Firestore 路线使用文档和客户端同步，SQL Connect 则是另一条由 PostgreSQL 支持的路线。应比较你实际打算采用的具体架构。

有没有比 Supabase 更合适的选择？

具体需求会有更合适的方案：Appwrite 适合可自托管的完整服务组合，Neon 适合以 Postgres 为先的迁移，Nhost 适合 GraphQL，Firebase 适合 Firestore 的移动端工作流，Convex 适合响应式数据函数。没有具体需求时，继续使用往往更好。

Firebase Studio 为什么要关闭？

Google 文档说明，Firebase Studio 将于 2027 年 3 月 22 日停止服务，并引导现有工作区用户转向 Google AI Studio 或 Google Antigravity。其 Studio 通知 并未说明更深层的商业动机，同时明确表示，核心 Firebase 产品和已部署的应用不受影响。

什么产品会替代 Google Firebase？

上述通知没有指定一个替代 Firebase 后端的统一产品。其中提到的迁移目的地，针对的是 Firebase Studio 开发环境。只有当另一后端的数据库、托管方式或应用模型更适合需求时，才应考虑更换。

使用 Firebase 有哪些缺点？

在 Firestore 路线上，现有 SQL 应用需要采用不同的数据和查询模型。生产服务仍绑定 Google 的托管基础设施，按量计费也需要逐项关注资源。Spark 同样没有包含完整后端所需的每一项服务。

Firebase 现在发生了什么变化？

Firebase Studio 正在退役，但 Google 表示，核心 Firebase 后端产品不受影响。不要把工作区产品的生命周期，与 Firestore、Authentication 或其他后端服务是否可用混为一谈。

决定迁移之前，可用 AI 业务工作流审查清单 梳理后端必须支撑的工作流程。