PocketBase vs Supabase vs Appwrite：开源 BaaS 怎么选
后端即服务（BaaS）这几年从 Firebase 一家独大，到现在开源阵营里冒出不少强手。如果不想被厂商锁定，又不想自己从零搭认证、数据库、文件存储和实时订阅，那开源 BaaS 几乎成了自托管玩家的首选。但在 PocketBase、Supabase、Appwrite 这三个名字之间到底怎么选，差别比想象的大——它们并不是同一类产品的不同实现，而是三条路线。
三个项目的定位差异
PocketBase 的思路是”一个二进制文件搞定一切”。官方把它定义为一个”单文件后端”，下载下来不到 20MB，扔到服务器上 ./pocketbase serve 就能跑。它没有微服务，没有容器编排，所有功能——数据库、Auth、存储、Realtime、后台管理 UI——都塞进这一个可执行文件里。
Supabase 的官方口号是”开源版 Firebase”，但底层走的是完全不同的一条路：它本质上是一个托管在 Docker 上的完整 Postgres 平台，外加 GoTrue（认证）、PostgREST（自动生成 REST API）、Realtime（基于 Postgres 的逻辑复制）、Storage（基于 S3 兼容存储）等一组服务拼起来。它对标的不是 PocketBase 这种嵌入式工具，而是 Firebase 这种全托管 PaaS。
Appwrite 走的是第三条路——”面向移动端和全端开发者的 Firebase 替代”。它从第一天起就强调 Flutter、iOS、Android、React Native、Web、Server 端的多端 SDK 矩阵，Console（后台管理界面）做得非常细致，权限粒度按集合、文档、用户角色逐层设置。它底层用的是 MariaDB（曾经是 MongoDB 的兼容层，后切到 MariaDB），不是 Postgres。
数据库是最大的分水岭
这一点几乎决定了后面的所有选型决策：
- PocketBase：内嵌 SQLite，单文件数据库。优势是部署零依赖、备份就是拷一个
.db文件；劣势是 SQLite 不适合高并发写入，也不支持横向扩展。官方文档也明确把它定位在中小规模、个人项目和 MVP。 - Supabase：原生 Postgres，全部能力（行级安全策略 RLS、JSONB、GIS 扩展、全文搜索、pgvector 等）都能直接用。这也是它被很多创业团队和 AI 应用开发者选中的原因——你需要的数据库能力它基本都覆盖。
- Appwrite：MariaDB（以前是 MongoDB 风格的文档 API，后来全面切到关系型）。功能上比 Postgres 略弱，但开箱即用的文档存储模型和细粒度权限让它在移动端场景里非常顺手。
| 维度 | PocketBase | Supabase | Appwrite |
|---|---|---|---|
| 数据库 | 内嵌 SQLite | Postgres | MariaDB |
| Auth | 内置（邮箱/社交/OTP） | 内置 + GoTrue | 内置（细粒度权限） |
| 文件存储 | 本地文件系统 | S3 兼容对象存储 | 本地或 S3/DO Spaces 等适配 |
| Realtime | 内置（SSE） | 基于 Postgres 逻辑复制 | 内置（WebSocket） |
| 函数/钩子 | JS Hooks（沙箱） | Edge Functions（Deno） | Cloud Functions（多运行时） |
| 后台 UI | 内置 Admin UI | Supabase Studio | Appwrite Console |
> 表中能力以各自官方文档为准，第三方插件和社区扩展不在统计范围内。
易用性：上手成本差很多
PocketBase 的入门门槛最低。下载二进制文件，解压，运行，浏览器打开 :8090/_/ 就是后台管理界面，创建 collection、加字段、写几条记录，整个过程几分钟就能完成。对前端开发者或者独立开发者来说，几乎没有运维负担。
Supabase 的上手曲线稍高，主要高在两处：一是 Docker Compose 部署涉及十几个容器（Studio、GoTrue、PostgREST、Realtime、Storage、Meta、Analytics、Vector、Edge Functions 等），默认配置需要一定调整；二是 Studio 虽然好用，但要真正发挥 Postgres 的能力，最好懂一些 RLS 和 SQL。不过它的官方文档和中文社区资料是三家里最完善的，碰到问题基本能搜到答案。
Appwrite 的 Docker 部署也比 PocketBase 复杂，但比 Supabase 简单一点（核心服务大约 5-6 个容器）。它最大的亮点是 Console——权限、用户、集合、函数、存储、Webhook、API key 全部可视化配置，新手也能照着文档搭出可用的后端。
{{图：PocketBase 单文件启动后浏览器访问 _/ 后台管理界面的截图}}
部署与运维
PocketBase：最简单。一个二进制 + 一个数据目录，可以用 systemd 跑，也可以塞进 Alpine 镜像里。备份就是定时 cp 数据库文件。
Supabase：自托管需要 Docker Compose 或 Kubernetes。官方提供了 supabase/self-hosted 仓库，但生产环境一般推荐用托管版或用外部 Postgres 替换内嵌容器。运维涉及多服务监控、日志聚合、备份恢复等，适合有一定经验的运维团队。
Appwrite：同样提供 Docker Compose，自托管门槛介于两者之间。官方也提供云托管版（Appwrite Cloud）作为快速起步方案。
{{图：Supabase 自托管仓库 docker-compose.yml 中各服务的关系图}}
适用场景：谁该选谁
选 PocketBase 的典型情况：
- 个人项目、博客后端、小工具的 backend
- MVP 阶段，需要几天内出可演示原型
- 不想碰 Docker、不想管多个容器
- 写入并发不高（几百 QPS 以内基本没问题）
- 数据量在 SQLite 能承受的范围内（一般几 GB 以内）
选 Supabase 的典型情况：
- 需要 Postgres 的全部能力（GIS、pgvector、复杂查询、RLS）
- 做 AI 应用（RAG、向量检索）
- Web 应用为主，需要 Row Level Security 做精细权限
- 团队规模足够承担多容器运维
- 想用 Edge Functions 做轻量 serverless
选 Appwrite 的典型情况：
- 移动端或全端项目，Flutter/React Native 原生支持很重要
- 团队习惯用 Console 可视化配置，权限模型要细到角色+集合级
- 数据结构相对简单，不需要 Postgres 那种重武器
- 想要”类 Firebase”的开发体验但不要被 Firebase 锁定
选择建议
一个粗略的判断框架：先问自己两个问题——数据库是不是核心瓶颈？ 如果是（比如你需要复杂查询、GIS、向量检索），基本只能在 Supabase 里选；如果不是，再问部署复杂度能不能接受？ 能接受多容器运维、想要全功能，选 Supabase；想要移动端 SDK 矩阵和好用的 Console，选 Appwrite；想十分钟跑起来一个后端，选 PocketBase。
也要反过来想”不该选谁”：别用 PocketBase 扛高并发写，别用 Supabase 当 SQLite 用（自托管成本高），别用 Appwrite 跑对 Postgres 强依赖的功能。
最后提醒一点：三家的功能边界一直在变——Supabase 在补移动端 SDK、Appwrite 在加 Edge Functions、PocketBase 也加了 JS Hooks 和更完善的 Realtime。具体能力、定价、自托管要求以各自官网最新文档为准，本文对比的是大方向。
延伸阅读
如果你想进一步了解每个项目的详细使用体验，可以看这几篇深度评测：
评论(0)