BaaS 项目对比

BaaS（Backend as a Service）把数据库、认证、文件存储、实时同步、函数和 API 放到一个平台里。对于海外 SaaS MVP，BaaS 的价值是减少后端样板代码；它的风险是权限、迁移、费用和平台耦合很容易被推迟到生产以后才暴露。

本文比较 Supabase、Appwrite、Firebase、AWS Amplify、Convex、PocketBase 和 Hasura 的定位，不对每家的实时额度和免费资源做长期承诺，具体限制以官网为准。

先按后端模型选择

总表

Supabase：关系型 SaaS 的默认候选

Supabase 为每个项目提供 PostgreSQL，并围绕数据库提供 Auth、Storage、Realtime、Edge Functions、REST / GraphQL API 等能力。它适合表结构明确、关系较多、需要 SQL 查询和后台报表的 SaaS。

Supabase Auth 与数据库的结合是它的核心优势：用户认证后，应用可以通过 JWT 和 Row Level Security（RLS）控制行级访问。这样前端可以直接访问部分数据，但前提是 RLS 策略真的正确，不能只依赖隐藏按钮或前端过滤。

推荐的最小数据模型：

auth.users
  └── profiles
        └── organization_members
              └── projects
                    └── project_members

每张业务表都要考虑 organization_id 或项目归属，并用 RLS、数据库约束和后端服务角色共同保护数据。服务端的高权限 Key 不能下发到浏览器。

Supabase 适合：

• B2B SaaS、后台管理和订单类关系数据；
• 需要 SQL、事务、视图、函数和报表；
• 希望未来可以迁移到标准 PostgreSQL；
• 想把认证、文件和实时更新放在同一个项目里。

Appwrite：开源全栈后端

Appwrite 提供 Auth、Databases、Storage、Functions、Realtime、Messaging 和 Sites 等产品，也支持 Cloud 与自托管。它更像一套完整后端平台，而不是围绕某一种数据库提供 API。

Appwrite 的权限模型覆盖数据库、表、行、Bucket 和文件，适合想通过平台 API 管理访问控制的团队。自托管时需要自己管理数据库、Docker、版本升级、备份、监控和公网安全。

它适合：

• 希望保留自托管路径的个人或小团队；
• 移动端和 Web 都要接入统一后端；
• 需要 Auth、Storage、Functions 和 Messaging 的完整组合；
• 不想一开始就直接设计大量 SQL 和 RLS 策略。

Convex：实时 TypeScript 后端

Convex 把数据库查询、Mutation、Server Functions、Realtime、Scheduler 和客户端库放在一套 TypeScript 模型里，适合实时协作、Dashboard、AI 应用和希望减少 API 样板代码的团队。

它的优势是端到端类型和响应式数据更新，代价是数据模型、查询方式和运行时更偏平台专属。需要复杂 SQL、跨平台报表或明确 PostgreSQL 迁移路径时，Supabase 仍然更自然。

PocketBase：单体 MVP 和轻量自托管

PocketBase 是基于 SQLite 的轻量后端，内置认证、文件、Realtime 和管理界面，适合个人项目、内部工具、演示和低流量单体 MVP。

它启动成本很低，但不应把单实例 SQLite 默认当成高并发 SaaS 的长期架构。需要水平扩展、复杂事务、读写分离或多区域部署时，应尽早评估 Supabase、标准 PostgreSQL 或其他托管数据库。

Firebase：实时和移动生态优先

Firebase 适合移动应用、实时同步和 Google Cloud 生态。常见组合包括 Firebase Authentication、Cloud Firestore、Realtime Database、Cloud Storage 和 Cloud Functions。

Firestore 的文档模型适合以用户、房间、消息、设备和状态为中心的数据；但报表、跨实体查询和复杂关系需要额外建模或导出到其他系统。规则文件就是安全边界的一部分，不能把数据库规则当成最后再补的配置。

Firebase 适合：

• 移动端优先的产品；
• 实时聊天、协作状态和推送；
• 已经深度使用 Google Cloud；
• 团队接受托管平台和 NoSQL 数据建模。

Amplify：AWS 服务编排层

AWS Amplify 更像 AWS 生态的应用开发入口，可以把 Cognito、AppSync、S3、Lambda、CloudFront 等服务组合起来。它适合团队已经在 AWS 上运行，并且愿意直接面对 IAM、区域、网络和资源配置。

Amplify 的优点是 AWS 能力丰富，缺点是问题往往不再停留在 Amplify 层：权限、CloudFormation、Cognito、AppSync、S3 和 Lambda 的排障都需要 AWS 经验。对一个只想验证想法的团队，整套 AWS 生态可能过重。

Hasura：已有数据库上的 GraphQL 层

Hasura 适合已经有 PostgreSQL、MySQL 或其他数据源，希望快速暴露 GraphQL API、权限规则和远程服务的团队。它更像数据库与业务服务之间的 API 层，不是开箱即用的完整用户系统或文件平台。

使用 Hasura 时，数据库约束、JWT Claims、行列权限和业务 Action 都要明确设计。简单 CRUD 项目可以很快上线，但复杂领域逻辑仍应放在自己的服务中，不要把所有业务规则塞进 API 配置。

认证不要和 BaaS 绑定得太死

BaaS 内置 Auth 很方便，但 SaaS 的身份系统可能需要独立演进。例如：

• Supabase 数据库 + Clerk 认证；
• Firebase 数据库 + 外部身份提供商；
• Appwrite 作为数据和文件后端，另接企业身份系统。

Supabase 官方也支持把第三方身份提供商用于 Data API、Storage、Realtime 和 Functions。选型时不要只问“有没有 Auth”，还要问能否把用户身份、组织和权限以标准 JWT / OIDC 方式接入。

权限和数据隔离

MVP 最容易出现的错误是所有用户共用一套读写权限。至少要定义：

把权限策略写成测试用例，覆盖正常用户、跨组织访问、被移除成员、匿名用户和服务端任务。BaaS 的“自动 API”不能替代权限设计。

迁移和成本检查

• 数据库是否能导出为标准格式；
• 文件是否能批量导出并保留元数据；
• Auth 用户是否可以迁移密码哈希或要求重新登录；
• 实时功能是否依赖平台专属协议；
• Functions 是否依赖平台运行时；
• 免费资源耗尽后，数据库、带宽、存储和函数如何计费；
• 是否有项目暂停、休眠、连接数和并发限制。

怎么选

结语

海外 SaaS MVP 最常见的起点是 Supabase：Postgres、Auth、Storage 和 Realtime 足以覆盖很多产品。需要自托管时看 Appwrite，移动和实时生态优先看 Firebase，AWS 团队再考虑 Amplify。无论选择哪一个，先把权限、导出、备份和迁移边界写进设计文档。