停止搭建服务器。开始交付代码。（Supabase、Appwrite 与 BaaS 革命）
Source: Dev.to
请提供您希望翻译的文章正文内容（除代码块和 URL 之外的文字），我将为您翻译成简体中文并保持原有的 Markdown 格式。
传统后端开发的痛点
“你花了两天时间去设置认证，才写下一行业务逻辑。
你配置数据库。你接入 JWT 令牌。你编写密码重置流程。你管理文件上传端点。你处理 CORS。你设置邮件验证。你在三个不同的地方配置环境变量。
然后——终于——你开始构建你真正想要构建的东西。”
这就是 Backend‑as‑a‑Service (BaaS) 平台要解决的问题。在 2024‑2026 年，两个名字屡屡被提及：Supabase 和 Appwrite。
BaaS 为每个应用提供所需的基础设施原语——已经构建、已经安全、已经可扩展——因此你可以直接跳到真正的产品上。
可以这样想： 与其每次做饭都从头建一个厨房，不如有人直接交给你一个装备齐全的厨房。你只需要……做饭。
每个 BaaS 提供的核心原语
| 原语 | 功能说明 |
|---|---|
| Database | 存储并查询您的数据 |
| Authentication | 用户注册、登录、OAuth、会话 |
| Storage | 文件、图片、文档 |
| Realtime | 实时推送更新至客户端 |
| Functions / API | 无需管理服务器的自定义后端逻辑 |
Supabase
Tagline: “在周末构建，规模扩展至数百万。”
Supabase 是 Postgres‑first —— 世界上最受信赖的关系型数据库。没有专有格式，没有奇怪的文档存储限制。真实的 SQL、真实的连接、真实的索引。你的数据永远属于你。
功能
| 功能 | 详情 |
|---|---|
| Database | 完整的 PostgreSQL。使用可视化表编辑器 或 编写原始 SQL。支持视图、物化视图、外部表、分区表、存储过程——完整的 Postgres 功能集。 |
| Auth | 电子邮件/密码、魔法链接、OAuth（Google、GitHub、Twitter、Apple，…），通过短信进行手机号认证。可使用预构建的 UI 组件或 SDK 进行集成。 |
| Row‑Level Security (RLS) | Supabase 的超级能力（也是最大的学习曲线）。编写 Postgres 策略，控制每个用户可以读取或修改的行。 |
| Storage | 兼容 S3 的文件上传、图片转换、CDN 分发，以及遵循认证规则的访问策略。 |
| Realtime | 订阅数据库变更并实时推送更新到已连接的客户端——非常适合多人游戏、实时仪表盘、聊天等场景。 |
| Edge Functions | 在全球范围内部署 TypeScript 函数，靠近用户。基于 Deno 的运行时。 |
| Instant APIs | 每个表在创建后立即自动生成 REST 和 GraphQL 端点。无需编写控制器代码。 |
| MCP Support | AI 工具（Claude Code、Cursor，…）可以检查你的模式，建议 RLS 策略，并编写迁移脚本。 |
| Self‑hosting | 可以自行托管，但涉及多个 Docker 容器（Postgres、PostgREST、GoTrue、Realtime、Kong，…）。可行，但组件繁多。 |
示例 RLS 策略
create policy "Users can view own profile"
on profiles for select
using (auth.uid() = user_id);考虑因素
- RLS 功能强大，但对初学者不友好；需要一定的学习曲线。
- Edge Functions 运行在 Deno 上，而非 Node——如果你来自纯 Node 背景，需要做一点调整。
- 自行托管 复杂；托管云服务可以免除这些负担。
Appwrite
Tagline: “Developer‑experience‑first.”
Appwrite 为跨平台团队而生——包括 Web、移动端（React Native、Flutter、iOS、Android）以及服务器端——并希望所有功能都集中在同一个 SDK 中。
Features
| Feature | Details |
|---|---|
| Auth | 所有标准认证流程 外加 匿名用户（可转换为真实账号）、手机号/SMS 认证以及内置的团队/成员管理。 |
| Database | 基于文档模型的集合和属性。虽然不是纯 SQL，但支持关系和索引。可视化控制台对非技术同事非常友好。 |
| Storage | 带权限的文件桶，支持图片转换（缩放、裁剪、格式转换），并内置病毒扫描。 |
| Functions | 超过 30 种运行时，涵盖 13 种语言：Node、Python、PHP、Ruby、Go、Dart、.NET、Kotlin、Java、Bun 等。你不必局限于 TypeScript/Deno。 |
| Messaging | 独家于 Appwrite：推送通知、邮件和 SMS 统一 API（无需自行拼接 Twilio、SendGrid、FCM 等）。 |
| Realtime | 订阅 任意 Appwrite 事件——数据库变更、认证事件、存储事件、函数完成等。 |
| Sites | 托管前端。支持 Git 关联部署、按分支生成预览 URL——全栈一站式。 |
| Security | DDoS 防护、静态与传输加密、GDPR 合规、SOC‑2、HIPAA——默认即提供，而非后加功能。 |
| Self‑hosting | 需要 Docker 以及一定的服务器管理知识。Appwrite Cloud 可实现无缝使用；如果预算有限，自己托管也是可行的。 |
Considerations
- Appwrite 的数据库是 文档型（类似结构化的 MongoDB）。如果你需要复杂的关联查询、报表查询或关系型数据模型，Supabase 的 Postgres 更合适。
- 自托管相较于 Supabase 更简易（单一 Docker Compose），但仍然需要一定的运维知识。
快速比较
| 功能 | Supabase | Appwrite |
|---|---|---|
| 数据库 | PostgreSQL (full SQL) | Document DB (NoSQL‑ish) |
| 认证 | ✅ Excellent | ✅ Excellent |
| 存储 | ✅ S3‑backed | ✅ Built‑in |
| 实时 | ✅ DB change streams | ✅ All events |
| 函数 | TypeScript/Deno | 13 languages, 30+ runtimes |
| 消息 | ❌ Not included | ✅ Push, Email, SMS |
| 前端托管 | ❌ Not included | ✅ Sites included |
| 自托管 | ✅ Complex (many containers) | ✅ Easier (Docker) |
| 最佳适用场景 | SQL lovers, complex queries, AI apps | Multi‑platform teams, mobile, polyglot stacks |
经验法则：
- 如果你的团队习惯使用 SQL 和关系模型 → Supabase。
- 如果你的团队跨多个平台或语言开发 → Appwrite。
结论
两个平台都消除了繁琐的“two‑day auth setup”阶段，让您专注于真正重要的产品。请选择与您团队技能和项目需求相匹配的数据模型和生态系统的那一个。祝开发愉快！
Firebase (Google)
- 优点: 经受实战考验，庞大的 SDK 生态系统，出色的离线支持。
- 缺点: NoSQL（Firestore），锁定于 Google Cloud，规模化时费用可能出乎意料。
- 新特性: Firebase Data Connect 现在加入了 Postgres + GraphQL，缩小了与 Supabase 的差距。
最佳适用场景: 移动优先的应用，已在 Google Cloud 的团队，实时体验。
PocketBase
单个 Go 可执行文件。将其放在服务器上即可运行。包括：
- 数据库（SQLite）
- 认证
- 文件存储
- 实时
- 带内置管理界面的 REST API
MIT 许可证 – 完全免费。
./pocketbase serve
# That's it. Your backend is running.注意：SQLite 不适合大规模多租户 SaaS。非常适合副项目、内部工具、原型，或任何不需要水平数据库扩展的场景。
最佳适用：独立开发者、原型、内部工具、小型应用。
Nhost
与 Supabase 类似（底层使用 Postgres），但所有操作都通过 Hasura 的 GraphQL 进行。如果你的团队以 GraphQL 为本，且希望在该工作流中使用实时订阅，Nhost 会显得非常自然。
适用场景：以 GraphQL 为首选的团队，需要实时功能的 JAMstack 应用。
Convex
一种不同的思维模型。你的后端逻辑存在于 TypeScript 函数中，这些函数会自动响应数据变化。无需 SQL 策略，也不需要设计 REST 端点——只有响应式的 TypeScript 函数。如果你是 TypeScript 为先，这真是优雅至极。
Best for：希望使用响应式模式而不想面对基于策略的认证复杂性的 TypeScript 重度团队。
Neon
有时你只想要一个无服务器的 Postgres，具备分支、空闲时自动挂起以及零规模计费。Neon 正好提供这些——不多也不少。你自行提供身份验证（Clerk、Auth.js 等）和存储。
最佳适用对象：那些清楚自己需求，并希望自行组装而不使用完整 BaaS 套件的团队。
决策树
Do you need complex relational queries / SQL?
├─ Yes → Supabase
└─ No → Keep going
Are you building for mobile + web + possibly other platforms?
├─ Yes → Appwrite (best multi‑platform SDK support)
└─ No → Keep going
Is this a small app, tool, or prototype?
├─ Yes → PocketBase (zero cost, zero ops)
└─ No → Keep going
Is your team GraphQL‑first?
├─ Yes → Nhost
└─ No → Keep going
Is your team TypeScript‑first and wants reactive patterns?
├─ Yes → Convex
└─ No → Supabase or Appwrite — pick based on DB preferenceWhy Use a BaaS?
Before BaaS
- 编写认证逻辑。
- 设计令牌系统。
- 实现密码重置流程。
- 配置电子邮件。
- 设置文件上传。
- 编写访问控制中间件。
- 在构建实际产品之前完成所有这些工作。
After BaaS
- 调用
supabase.auth.signUp()或account.create()然后继续。
在基础设施搭建上节省的时间会被重新用于面向用户的功能，这些功能让你的产品更出色。这才是这个类别的真正论点——不仅仅是更容易（虽然确实如此），更在于它彻底改变了你花时间的地方。
快速回顾
| BaaS | 何时选择 |
|---|---|
| Supabase | 想要拥有 Postgres 的强大功能，同时集成认证、存储、实时和边缘函数；并且对编写 SQL 策略感到自如。 |
| Appwrite | 需要最广泛的平台支持（尤其是移动端），内置消息、前端托管以及灵活的函数运行时。 |
| PocketBase | 想在小型项目上快速迭代且无需任何月费。 |
最佳的 BaaS 是能够为 你的技术栈和团队消除阻力的那一个。三者都做得很好——区别在于细节。
你目前在后端使用什么？
想了解 dev.to 社区的选择——在评论中告诉我们吧。
作者 md8‑habibullah
Tags: supabase appwrite webdev backend beginners