比较 AWS 的 RDS 和 PlanetScale

发表于： 2025年5月20日 2025年5月20日
分类：数据库

我们对开发者社区对 PlanetScale 产品的反响感到欣喜，但更令人惊讶的是，最近有越来越多的客户从 Amazon RDS 转向 PlanetScale。我将尽力快速阐述为什么有如此多的企业从 AWS RDS 转向 PlanetScale的主要原因。

Amazon RDS 是由 Amazon Web Services 提供的关系数据库服务。本质上来说，RDS MySQL 是运行在云中的数据库。PlanetScale 同样是一种基于云的 MySQL 数据库，但它特别注重无限扩展潜力和以开发者为中心的设计。目前选择 RDS 的主要优势是其对 Postgres 的支持。因此，如果你对 Postgres 情有独钟，那么 RDS 依然是你的最佳选择。然而，如果你需要的是一个能够随着企业增长而扩展的数据库，并且能够轻松融入开发者的工作流程，那么从 RDS 转向 PlanetScale 就显得非常明智了。以下是我们观察到的企业和开发者离开 RDS 转向 PlanetScale的两个主要原因：可扩展性和开发者工作流程。

注：
🚀 想深入了解 PlanetScale 和 RDS 的对比？请访问我们的PlanetScale vs Amazon RDS 对比页面。

AWS RDS 与 PlanetScale 的功能对比表

RDS 的连接限制以及其他可扩展性问题

可能令人意外的是，像 AWS 产品中的 RDS 这样强大的服务竟然存在扩展性限制。但事实证明，单纯主机化数据库还远远不够。扩展业务的数据库层不仅需要更强大的资源和更大的机器，还需要能适应数据库连接需求的扩展能力。

PlanetScale 基于 Vitess 构建，这是一个开源的数据库集群系统，诞生于 2010 年，旨在支撑 YouTube 的扩展。目前，Vitess 数据库技术还在为 GitHub、Pinterest 等一些全球领先的互联网公司服务。

凭借 Vitess 和 PlanetScale，企业可以扩展到几乎无限量的连接数。我们最近进行了基准测试，证实了 PlanetScale 数据库支持一百万个并发连接的能力。接下来，我们会深入探讨相关细节。

以下所有指标数据都基于实际应用的 Vitess 集群：

可扩展性问题 1：连接限制

RDS 将连接数限制在 16,000，而 PlanetScale 设计使其每个数据库能够支持接近无限量的连接。虽然你可以手动升级 RDS 并将连接数设置为 16,000，但这需要自己去管理连接池，并进行繁琐的配置。而对于现代 Web 应用程序开发者来说，这些应用通常需要处理数千个来自不同客户端的同时连接，这种连接上限无法实现有效扩展。

可扩展性问题 2：连接池问题

连接池是一种经典的数据库访问模式，它使得数据库连接保持活跃，从而在后续请求时可以直接利用现有的连接，而无需重新创建新的连接。虽然 RDS MySQL 支持创建最多 16,000 个连接，但连接池的管理需要开发者自己来实现。相较之下，PlanetScale 和 Vitess 优雅地管理连接池的状态，开发者无需担心连接问题，只需专注于向数据库发送查询即可。

加分特性 — 查询合并

Vitess 还能自动让多个客户端同时通过一个单次查询服务相同请求。我们看到许多客户在 NoSQL 或 RDS 数据库上的宕机事件，通常是由于查询响应时间突然激增导致的级联式宕机。这种问题在特定流量模式（例如网站的季节性流量高峰）下尤为频繁。Vitess 的解决方案是识别查询请求中的峰值，让多个几乎同时发起相同查询的客户端共享相同的连接。

可扩展性问题 3：RDS 的总成本

对大多数企业而言，价格可扩展性可能是最重要的因素。虽然 RDS 的价格结构非常清晰（其定价页面有 2740 个单词，字数大约是披头士《Abbey Road》专辑总词数的 20%），但其僵化的设计不适用于快速增长的数据库使用需求或需求快速上下波动的场景。与之相比，PlanetScale的定价策略非常灵活，支持按使用付费，同时还提供混合模型，允许企业自带资源或按机器计费（如果有需求可以联系销售团队讨论这种模式）。

最终切换到 PlanetScale，让我们节省了 20-30% 的成本。— Barstool Sports

PlanetScale 的开发者工作流程与非阻塞式架构变更

如果你阅读 G2 等平台上关于 AWS RDS 的用户评价，你会发现大多数负面评论都集中在产品复杂性以及学习曲线上。当我们设计 PlanetScale 的云产品时，我们着重从开发者体验角度优化数据库系统，通过简化使用时间、改进架构变更和 CI/CD 流程，为用户带来更便捷的体验。

非阻塞式架构变更

在 RDS 上执行架构变更相当复杂，通常需要使用多个外部库，更糟的是，这还可能需要停机或维护窗口。在如今工具日益现代化的情况下，这正在变得越来越难以接受。开发团队期望使用的工具能够更方便地实现零停机的持续部署。然而，对于 RDS 数据库，这基本上需要开发团队自行编排复杂的流程。

PlanetScale 的非阻塞式架构变更特性让这一切成为了现实。你可以直接在 CLI 或 Web UI 上部署架构变更。此外，PlanetScale 还会自动检查上游分支的变更并告诉你是否安全进行部署。

短评：PlanetScale 对迁移不需要维护窗口，也无需停机。

分支环境与 CI/CD 工作流自动化

PlanetScale 的数据库分支功能让用户能够像在 GitHub 管理代码分支一样操作数据库。这一功能使开发者可以轻松创建一个数据库分支，进行修改测试，随后将更改重新部署到主数据库。这不仅是一个巨大的时间节省，还显著提升了开发人员的工作效率。

相比之下，RDS 的开发者推荐使用 mysql_dump 来复制 AWS MySQL 生产数据库用于创建阶段性环境，这无疑增加了繁琐的步骤。为了简化这一过程，PlanetScale 推出了数据库分支功能，能够帮助团队无缝管理数据，更快进行部署。

PlanetScale 支持通过命令行 (pscale CLI) 轻松创建和管理分支，并将 CI/CD 工作流整合进开发工作流程中。例如，你可以参考我们的博客文章《使用 PlanetScale CLI 与 GitHub Actions 工作流》获取更多指导。

总结：创建一个最新的阶段性环境，不应该需要向数据团队提需求单。通过 PlanetScale，这个过程变得简单直观。

开发工具与文档的优势

开发者选择切换到 PlanetScale 的最后一个主要原因是文档和工具的优越性。我们收到的许多客户反馈都提到，设置新的 RDS 资源需要耗费几个小时的开发时间，仅仅是配置步骤就显得繁琐冗长。而在当今的标准化、自动化趋势下，这显然不符合时代的需求。

为新的 RDS 数据库实例配置资源需要完成一系列前置步骤以及接下来的 13 个具体操作。相比之下，在 PlanetScale 中，数据库可以瞬间完成配置和部署，而且每个实例都支持几乎无限的连接数量、数据库分支和查询洞察功能。这一对比显然不在一个层面上。

如果你希望看到过程的具体差异，可以立即注册 PlanetScale 试用，并亲自创建一个数据库，体验全流程。

关键要点总结

显而易见，AWS RDS 主要是为传统行业的大型企业服务，这些企业的工程团队有足够的时间和资源来应对复杂的调整和定制，并且通常工作节奏较慢（例如 Aurora 仍然停留在 MySQL 5.7，不支持最新的 MySQL 8）。但对于其他所有快速发展的企业来说，我们优先优化了速度与扩展性。

RDS 提供了丰富的定制选项，但同时需要更多的数据库管理员 (DBA) 来管理数据存储。这种高负担对于快节奏的业务来说毫不友好，尤其是不在扩展过程中为用户提供更高的灵活性。RDS 在连接数限制、备份副本数量限制以及定价刚性等方面都存在明显问题，这迫使企业在扩展自身业务的同时花费更大的成本和时间管理数据库，而不是减少管理负担。

相较之下，PlanetScale 为业务的快速扩展和开发者的敏捷工作流程做出了更多优化。虽然 PlanetScale 的定制选项不如 RDS 广泛，但它能在几秒内完成部署，帮助任何规模的企业（无论是否雇佣了专业的 DBA）轻松扩展数据存储，并像专家一样稳定运行。PlanetScale 提供了更好的开发者工作流程，减少了新功能上线时间和额外数据管理的开销。

如果你希望尝试 PlanetScale，可以使用数据库导入工具，这允许你在无需停机的情况下将 RDS 数据库迁移到 PlanetScale。此外，我们还有一份 RDS 迁移指南供你参考，了解更多细节。