啊，是的。Web开发世界的香草冰淇淋。

PostgreSQL是一个免费且开源的企业级关系型数据库，自1996年以来一直存在，并被广泛认为是世界上最可靠、性能最好的关系型数据库管理系统，支持JSON（非关系型）和SQL（关系型）数据。

如果你已经拥有一个服务器，你可能也可以在上面运行Postgres - 几乎每个主机都从第一层开始提供PostgreSQL。

我一直能够在几乎任何规格的服务器上很好地运行Postgres，而且设置也很简单。它在操作上可能会有一些复杂性和性能问题，但是如果出现问题，你很有可能会在网上找到一些帮助来帮助你恢复正常。Postgres的开源社区经验丰富、专注且充满激情。

优点

• 并发性能高，功能强大（你可以在任意JSON字段上进行JOIN操作...这意味着你可以完全在数据库中完成对REST API数据的提取、转换和加载！多酷啊！）

• 如果你有超出CRUD应用的特定需求（例如递归查询、窗口函数、部分索引、可扩展数据类型），没有比它更好的选择。

• 文档很棒。

缺点

• 编写优化查询以获取所需数据的能力非常重要。

• 一连接一进程的架构意味着维护TCP连接将是昂贵的操作（我使用postgREST服务器创建REST API）。

• 在像EC2这样的服务器上自托管Postgres将很快变得太昂贵。

如果像PostgreSQL这样的完整关系型数据库让人感到不知所措或成本过高，那么作为服务提供的托管无服务器数据库可能更适合你。这些关系型数据库可以自动扩展以满足波动的需求，并提供保证的正常运行时间和容错性，而无需你进行任何服务器操作。你只需要编写代码，只支付你使用的部分。

入门方法对所有这些数据库都是相同的。注册账号，选择一个计划（所有计划都有免费层），创建一个数据库，获取连接字符串，然后就可以开始使用了。

现在让我们来谈谈一些无服务器数据库。

说实话，这是满足你所有数据库需求的“简单模式”。以下是简要介绍：

• WunderBase是一个免费且开源的无服务器SQLite（！）数据库，

• ...使用Prisma ORM进行迁移，使用模式进行管理，

• ...具有GraphQL API（因此你可以直接获得实时订阅），

• ...在Fly Machine上运行（使用REST API的Firecracker VM），

• ...所有这些都在一个优雅、轻量级的Golang代理后面，该代理在收到网络请求时启动VM（冷启动时间为300-500毫秒），并在最后一个请求后自动关闭（可配置的）10秒钟。

非常简单。将一个Docker镜像部署到一个附加了卷的fly.io机器上（你甚至不需要自己构建镜像），然后就完成了！在这里可以找到本地试用的说明。

不过，请记住：WunderBase确实提供了一个GraphQL API，但是将其公开可能会带来安全性和性能方面的问题。最好使用API网关来使用它。 （如前所述，来自同一开发者的Wundergraph非常适合这个用途。）

首先，我要承认一件事：一开始，我对使用SQLite进行全栈开发有些怀疑。但是在尝试了WunderBase并阅读了LiteStream创建者@benbjohnson的这篇文章之后，我改变了看法。大多数Web应用程序更注重读取而不是写入，而SQLite - 顺带说一句，WunderBase - 正好适合这种情况，作为一个自包含、零配置的进程内SQL“服务器”运行。

我发现WunderBase非常适合原型设计，或者（终于！）让个人周末项目运行起来（存储需求<1 GB；流量较低）。它在本地和生产环境中都快速且易于设置。

然而，最让我兴奋的是WunderBase如何利用Fly Machines + SQLite成为唯一真正的“无服务器”数据库。几乎每个无服务器关系型数据库都有一个最低月费，即使你从不使用它...但是由于SQLite数据库实际上只是一个位于卷中的二进制文件，WunderBase可以通过在不提供请求时关闭Fly.io VM来实现零扩展。成本始终是一个因素，通过这种方式，你可以使基于Wunderbase的应用尽可能接近_免费_。

优点

• 快速设置；专注于需要比写入多几个数量级的读取的用例。

• 在fly.io上的Firecracker VM上运行，因此你处理的是无状态HTTP，而不是维护TCP连接 - 可以将基于WunderBase的应用部署到全球多个边缘位置，延迟低于100毫秒。

• 可以真正扩展到零 - fly.io的定价意味着如果你不使用它，你不需要支付任何费用。

• 原生GraphQL API。

• Wunderbase使用Prisma作为ORM，因此你可以通过编辑prisma.schema文件将SQLite替换为任何其他关系型数据库。

缺点

• SQLite的单写多读模型对于具有多个用户进行交互和执行更改的Web应用程序来说并不理想。

• 如果你的需求涉及大量数据或高流量，成本将不再低廉。

• 尚无开箱即用的备份功能，但你可以使用LiteStream将SQLite更改流式传输到AWS S3、Azure Blob Storage、Google Cloud Storage、SFTP或NFS。

作为开发者，PlanetScale的杀手级功能显然是分支功能。如果我可以像处理代码一样处理数据库：更改它、创建功能/测试分支，并像处理代码一样进行发布，那么我会非常关注。一开始可能会让你有些困惑，但如果你曾经使用过Git工作流程，你会很快适应。

然而，令人惊讶且限制性的是，它没有外键约束，即使他们有一些解决方法。更大的问题是仅支持TCP连接，而且由于PlanetScale是MySQL，我无法使用postgREST生成RESTful API。这真是令人沮丧。

优点

• 非常高效，非常弹性。我可以专注于我的应用代码，不用担心扩展问题。

• 通过分支机制，我可以像处理代码一样直观地对我的模式进行版本控制。

缺点

• 没有外键。就是，完全没有。

• 仅支持TCP连接，因此无法从Cloudflare Workers/Vercel Edge平台使用。

• 除了有限的免费层之外，还有最低月费，即使你从不进行任何读写操作。

FQL本身（作为特定于语言的DSL）让我想起了RethinkDB（我曾经喜欢它，RIP 🖤），但我发现Fauna最有趣的是它是一个_地理分布式数据库_ - 我可以自动将我的数据分区和分发到多个区域，这意味着我的数据将与我的应用一样接近我的用户 - 这使得它成为与Vercel和Netlify等无服务器/边缘时代非常契合的选择。

总体而言，与Fauna一起工作非常有趣，但从仍然编写查询的角度来看，我会在不是全新项目的情况下再三考虑将其集成到任何项目中，因为它不使用任何标准的SQL语言。### 开发需要了解的事项

首先：虽然Fauna提供了本地的GraphQL API，但从性能和安全的角度来看，将其用于客户端可能不是一个好主意。最好使用API网关来代替。例如Wundergraph就非常适合这个用途，并且可以与任何关系型数据库、PlanetScale、Fauna、MongoDB等等很好地配合使用。

优点

• 本地的GraphQL API使得Fauna非常适合JAMStack开发者，因为许多SSG（静态网站生成器）使用GraphQL作为数据层（如Gatsby、RedwoodJS）。

• 分布式数据库以及与Vercel和Netlify的本地集成使得Fauna成为无服务器/边缘时代的数据库的理想选择。

缺点

• 如果你的项目已经使用了SQL，那么集成可能会很困难，因为Fauna使用了一种专有的查询语言FQL（也有GraphQL选项）。不过，如果你使用WunderGraph，这个问题就解决了，因为它可以将所有数据源整合到一个单一的虚拟图层中，然后通过安全的、类型安全的JSON-over-RPC API在客户端访问。

• 再次强调，除了免费套餐之外，还有最低月度定价。

它作为Firebase的替代品效果很好，尽管功能的完全对等还有一段距离，而且Firebase和SupaBase之间没有交叉兼容性。对我来说，原生的REST API非常有用，因为我大部分构建的东西都托管在Vercel/Netlify上。

不幸的是，JS客户端的类型安全是一个问题；从模式生成类型需要使用第三方的命令行工具。在原生类型生成器出现之前，我建议使用Prisma + tRPC来实现端到端的类型安全。

优点

• 除了数据库之外，还提供了大量的功能。

• 使用postgREST提供了一个RESTful API，非常适合在无服务器/云函数中使用SupaBase。

• 可以自行托管，尽管目前文档不够清晰，有一些困难。

缺点

• 类型安全是一个问题（可能在未来的v2客户端中会有所改善）。

• 再次强调，除了有限的免费套餐之外，还有最低月度定价。

对于大多数人来说，MongoDB是事实上的NoSQL选项 - 大多数人最初开始进行Web开发时使用的是MERN堆栈。无处不在的M - MongoDB - 是一个跨平台的、源代码可用的*数据库，它将数据保存为（本质上）JSON文档，而不是相互连接的具有关系的表。

自行托管在VPS上，或者选择他们的托管选项MongoDB Atlas。

我已经使用MongoDB有一些年头了，如果（且仅当）你知道你的数据始终可以表示为CSV文件，并且你只需要额外的功能，比如理论上可以无限扩展的能力，那么它实际上比关系型数据库更快。

它还与Javascript和JSON很好地集成在一起 - 这是Web开发人员的基本工具。个人偏好，但我发现例如db.collection().find({})这样的语法在测试时很容易在IDE和Shell之间进行复制粘贴。我甚至不需要使用Mongoose。

优点

• 当你将其用于其预期目的 - 作为一个文档存储，用于非关系型数据时，它非常适合。

• 有一个活跃的社区，提供大量的教程和资源，甚至有一个ORM（Mongoose）如果你需要。

• 托管选项Atlas有一个按操作付费的无服务器计划，所以如果你不使用它，你可以将其缩减到零并且不需要支付任何费用。

• 开箱即用的实时更新、日志记录和自动化。

缺点

• 不是关系型数据库。

• Atlas在某些地区可能会很慢。

• 不是真正的开源；除非你的源代码是私有的非商业用途，否则你必须完全公开发布你的源代码 - 包括你使用的每个其他服务的代码，这可能使它成为一个不可行的选择。

这些是具有微小但非常快速存储的特殊数据库，它们只能存储键值数据。本质上是非常大的哈希表，可以通过网络连接，而且它们可以完全存在于内存中（但如果需要，可以持久化到连接的卷中）。

对于Cloudflare Workers KV，在这里注册。对于Redis，你可以选择来自DigitalOcean/Vultr/Upstash的托管Redis服务，或者只需将官方的Redis Docker镜像放在VPS上自行托管。

对于那些优先考虑低延迟的特定用例来说，这些数据库非常适合。如果你的数据可以表示为1:1数据映射的哈希表（例如userID到社交媒体个人资料URL的映射），那么恭喜你！现在，你的查找操作的时间复杂度变为O(log(n))甚至是O(1)，这太神奇了。

想要快速知道Bob是否关注Alice？想要保留你网站上最新帖子的列表，而不是每次都从API/RSS源查询？想要将订单作为customerID → itemID的映射持久保存，直到来自Paypal/Stripe的IPN确认到达？

这些高性能+低延迟的键值存储 - 尤其是在边缘位置提供的服务商 - 对你的需求来说是完美的。

这里跳过了优点/缺点，因为键值存储非常简单，但是这里有一个常见的问题：如果你使用的是托管的Redis服务，请首先确保它们与你将需要的Redis API的部分兼容（例如，许多提供商尚不支持Geo核心）。