过去，越来越多的文章都在讨论为什么 Firebase Firestore 不够好，以及其他替代方案更优越。由于我没有这方面的经验，我决定亲身体验一下 Firebase、Appwrite 和 Supabase 的数据库，并用它们构建了真实的应用。几周之后，我现在清楚地知道，针对不同的用例，我应该使用哪种数据库。下面是我为你总结的一份小小的摘要。
💡 俺是一个Dart/Flutter工程师。
对于其他技术栈的人来说, 结果可能不太一样。
欢迎关注我的公众号：OpenFlutter，谢谢
Firebase
让我们从 Firebase说起。
Firebase Firestore 是一个 NoSQL 文档数据库，也是 Google Firebase 服务的一部分。它使用文档和集合的层级结构来组织数据，并针对存储大量小型文档的集合进行了优化。将整个文件存储在其中并不实用，甚至是不可能的。
功能多，学习曲线友好，有免费套餐
说到文档和学习曲线，Firebase 表现得非常出色。你可以很快上手，在实践中不断学习。Firestore 包（以及所有 Firebase 包）都由 Firebase 团队精心维护并定期更新。
此外，Firebase 提供的不仅仅是一个数据库。身份认证（Authentication）、云函数（Cloud Functions）和 云存储（Storage）等功能，也是许多应用所需要的。既然如此，为什么不使用一整套服务呢？
作为入门，它提供了一个慷慨的免费套餐（Spark plan） ，足以支撑你的最小可行产品（MVP）。在这个套餐下，你无需支付任何费用，但当超出限制时，服务会停止。不过，升级服务只需几分钟就能搞定。
费用，规则，无 Schema
Firebase 最大的缺点（就 Firestore 而言）可能在于它的定价方式。你需要为读、写、删除操作付费，并且有每日或每月配额，这使得它的收费模式比每月固定支付 5 美元更难理解。
接着是安全规则。除了 Firebase，没有其他系统有这种概念。它对许多人来说是全新的，而且遗憾的是，当你改变集合和文档时，很容易忘记修改规则。如果出了问题，系统也不会给你任何警告。
如果你需要数据验证，Firestore 可能不是你的朋友。它不在乎你所有的文档是否包含相同的字段。你可以为所欲为。这对于无组织的数据听起来可能不错，但它也要求开发者遵循严格的编码规则，并做好客户端的验证。
过去，我写过很多关于 Firestore 的文章。所以如果你想深入了解，可以查看我的其他文章（这里、这里、这里），或者直接下载 Flutter Firebase Compendium，学习关于 Firestore、身份认证、云函数等的一切！
Supabase
Supabase 是一个开源的 Firebase 替代品，可以自行部署。它的诞生就是为了回应那些对 Firebase 各种抱怨的人。在数据库方面，Firebase 和 Supabase 的差异非常大。
Supabase 提供了一个 PostgreSQL 数据库，具备你所期望的所有功能（SQL 编辑器、表格可视化、函数、触发器、角色、扩展、备份、迁移等）。当你需要一个带有复杂关系、用于专业应用的数据库时，它就是你的选择。我喜欢 Firebase，但我绝不会用 Firestore 来开发那些数据库很重的应用。
虽然 Firestore 有一些查询机制，但 Supabase 在这方面要好得多。你可以定义数据库 Schema，使用 SQL 编辑器快速操作任何东西，甚至可以从 CSV 导入数据。在填充数据库数据方面，Supabase 比 Firebase 更加方便。
如果免费套餐不够用，定价从每月 25 美元起。要在 Firestore 上达到这个金额，你每月需要进行大量的读、写和删除操作。不过，Supabase 提供了自行部署的选项，让你能完全掌控一切。
和 Firebase 一样，Supabase 也提供了身份认证（Authentication）、边缘函数（Edge Functions）和云存储（Storage）等功能。它是一个非常可靠的系统，但除了免费套餐，在我看来它的价格有点贵。
Appwrite
Appwrite 感觉就像是有人用了一段时间 Firebase，然后开始感到不满，于是转投 Supabase，但最终又和它们两者都保持着开放关系。如果它能变得更灵活一些，可能会成为一个非常厉害的系统。
它拥有基础功能：身份认证、数据库、云函数（甚至可以用 Dart 代码来写！），以及云存储（他们正在开发像 Firebase Hosting 一样的网站托管服务）。
Appwrite 也可以自行部署，定价同样从每月 25 美元起。
它的数据库（和 Firebase 一样）是一个 NoSQL 文档数据库，有集合的概念，但你不用像 Firebase 那样编写安全规则来管理访问。取而代之的是，你为表格和行设置权限（Supabase 也有类似的概念）。
默认情况下，它最大活跃会话数是 1，所以如果你不先退出登录就重启应用，下一次登录就会失败，因为旧会话还处于活跃状态。不过，只要你了解这个机制，就能修改这个设置。
Appwrite 没有内置的数据库内容导出功能。与 Firebase 和 Supabase 相比，这是一个主要的缺点。如果你依赖这项功能，请务必记住这一点！
结论
三个服务，对我而言有三种不同的应用场景。
- Firebase 是，也将永远是我的首选，只因为我详细了解它的一切工作原理。当我只需要一个简单的数据库和身份认证时，它是不二之选。
- Supabase 会是我的选择，当数据模型相当复杂，高效查询至关重要，并且需要一个性能优异的数据库时。从长远来看，SQL 在这方面就是比 NoSQL 强。
- Appwrite 是当 Firebase 不够好用（例如，我需要云函数，但不想用 JavaScript）或者 Supabase 功能过于强大时（例如，我用 NoSQL 更顺手）的解决方案。它感觉介于两者之间。但如果只是为了一个简单的数据库，我还是更喜欢 Firebase。
你会如何选择？