基础设施演进：我们为何从 Heroku Postgres 迁移到 Neon

我们最近完成了一次重要的后端迁移：将我们的主要生产数据库从Heroku Postgres 迁移到Neon。

此举并非为了追逐炫酷的新技术或急于求成，而是为了突破瓶颈，从而提升开发者体验，实现更流畅的扩展，并降低成本。Postgres 仍然是 DEV 和 Forem 的基石，但 Neon 为其提供了更灵活、更现代化的运行时环境，并为未来的发展奠定了基础。

现在迁移工作已经完成，我们想回顾一下这次迁移。我们现在受益于更低的成本、更高效的反馈机制以及更大的发展空间。

我们搬家的原因

首先，Heroku Postgres 为我们提供了很好的服务。它帮助我们快速启动并运行，从八年前我们最初的简陋平台到如今每月服务数百万开发者的应用，它一直是可靠的核心支持。但是，随着时间的推移，我们遇到了一些持续存在的痛点：

• 如果不进行大量工作，很难运行类似生产环境的程序。
• 读取副本的使用受到限制，而且有时不太稳定。
• 传统数据库僵化的资源分配方式导致扩展效率低下。
• 我们对资源的分配或计费方式几乎没有控制权。
• 我们预计未来会继续发展壮大，并使用多个数据库，而自动扩展功能将带来变革。

Postgres 历来是我们最大的单项资源支出——远远超过我们的计算和其他基础设施成本。它也至关重要，我们不会为了降低成本而降低它的成本，而是会同时找到升级和改进的方法。核心数据库太重要了，我们绝不能在这方面偷工减料。

因此，在考虑搜索方案时，我们不仅优先考虑成本效益，还优先考虑能够帮助我们尽可能地处理和保护数据的工具。

我们研究了许多方案，并与多家潜在合作伙伴进行了洽谈，最终确定 Neon 是最佳选择。我们联系了 Neon 团队，很高兴能与他们建立合作关系，最终促成了我们在 DEV 平台上的💎️钻石赞助合作，并为我们的 DEV++ 会员提供了更优惠的方案。

更高效的开发者循环

最大的胜利之一是开发者体验的提升。

Neon 的分支系统使我们能够立即启动隔离的数据库环境。这意味着：

• 我们可以使用真实数据，而不用担心冲突。
• 我们可以在真实的生产环境中测试迁移、模式更改或极端情况。
• 我们可以确保涉及数据库的功能预览实际上是可行的，而不会出现暂存瓶颈。

我们也更广泛地使用了只读副本，这在以前是需要谨慎对待的。Neon 让这一切变得简单得多。无论是卸载长时间运行的查询、为自动化工具提供支持，还是尝试特定功能的读取路径，启动副本都不再昂贵或复杂。

这为处理负载开辟了新的途径，并为我们提供了更具前瞻性的实验路径。

更智能的扩展，更低的成本

Neon 的架构将存储和计算分离。我们不必像 Heroku Postgres 固定规模产品那样，一次性扩展所有资源，这始终是一个令人头疼的限制。现在，我们可以独立调整存储和计算需求，只需为实际使用的资源付费。

成本方面的影响非常显著。自从改用Neon之后，我们的数据库费用大幅下降。

为未来发展留出灵活性

我们非常欣赏 PostgreSQL 扩展和现代工具的简洁性和易用性，这些工具我们目前尚未使用。这不仅仅关乎我们当下的需求，更关乎我们未来如何轻松集成强大的新功能。pgvector例如，原生支持让我们能够轻松使用语义搜索和推荐等 AI 驱动的功能。我们也渴望探索pg_search数据库内部更高级的全文搜索功能，从而简化我们的技术栈。除了搜索之外，围绕 API 和身份验证的生态系统工具也极具吸引力。利用 Neon Data API 等工具快速创建和公开数据端点，再加上强大的身份验证扩展，意味着我们可以比以往任何时候都更快地构建和保护新服务。对我们而言，选择 Neon 意味着确保我们的平台面向未来，并使创新变得更加触手可及。

迁徙

将数据库从 Heroku 迁移到 Neon 是一项重大工程，我们在整个过程中始终将确保零数据丢失和最小停机时间作为首要任务。为了实现这一目标，我们使用了一款名为 Bucardo 的迁移工具，它使我们能够在几乎零停机的情况下完成数据迁移。

Bucardo 是一个用于 PostgreSQL 的异步复制系统。它的工作原理是在主数据库上创建触发器来监视数据变更。这些变更会被收集并重放到目标数据库上，从而保持目标数据库与源数据库的同步。为了管理这个过程，我们与 Neon 团队紧密合作，在 DigitalOcean 的一个独立服务器上部署了 Bucardo。这使得 Bucardo 能够同时连接到我们的 Heroku 数据库和新的 Neon 数据库，并在不影响主应用程序性能的情况下实现数据复制。

虽然 Bucardo 最终证明是实现无缝过渡的正确选择，但它也并非完美无缺。有时，整个流程会有些小问题。虽然正常流程总是有效，但由于一些遗留的触发因素导致问题，我们不得不重新启动流程。

我们对数据完整性的高度重视也意味着我们没有充分预料到之后需要进行的配置调整。

我们使用 Heroku 已经很久了，它的数据库配置对我们来说就像呼吸一样自然——一些默认设置我们也习以为常。我们理所当然地认为数据库在任何情况下都会以同样的方式运行。这意味着迁移到 Neon 后，我们必须对配置进行微调，尤其是在连接池和超时设置方面，才能使一切发挥最佳性能。我们花了几天时间进行调整，最终才将性能提升到 100%，但我们成功了。

总体而言，迁移到 Neon 平台非常成功。我们实现了迁移的主要目标，实现了零停机和零数据丢失。现在，我们使用的平台拥有许多令人兴奋的新功能。我们仍然能够获得我们所期待的开​​发者体验（毕竟是托管在 Heroku 上的应用），同时还拥有更加灵活强大的底层基础架构。

接下来会发生什么？

我们已经开始将 Neon 的更多功能整合到我们的工作流程中：

• 分支即服务，用于功能预览
• 在不影响生产环境的情况下进行基于副本的实验
• 更清晰地分离开发环境和生产数据

虽然运行 Forem 不需要 Neon（Postgres 仍然是默认设置），但我们认为这种设置代表了严肃应用程序将日益依赖的那种现代基础架构。

最后想说

我们一直在寻找既能提升我们能力又不会限制我们发展的工具。Neon 为我们提供了一个更好的 Postgres 版本，减少了妥协，也提供了更大的灵活性。

我们很高兴当初做了这个决定。