48 小时内更改数据库 5 次，使我们的发布浏览量达到 35,000 次

GenAI LIVE! | 2025年6月4日

这个故事的开头和标题一样古怪。我从2021年开始从事“综合推理”项目，是为了探究如果在解决背包问题时可以使用任意精度的整数（例如9、33和65位寄存器）会发生什么。我的想法是，灵活的字长可以使解决背包问题的伪多项式时间算法更高效。简而言之，它确实有帮助，但最大的收益来自流水线技术。

时间快进到2024年4月中旬。我们刚刚开始开发IRX，这是一个优化即服务平台，用作Integrated Reasoning硬件加速求解器的接口。我们计划推出一个MVP（最小可行产品），将运行HiGHS等开源求解器的体验从命令行转移到浏览器。其卖点在于，这些流程可能需要数月甚至更长时间才能完成，而无需费力地处理这些流程，可以帮助我们的用户专注于优化，而不是运行优化所需的基础设施。

将日志从 AWS 实时推送到浏览器是我从未做过的事情。我认为这与LLM 的文本流式传输问题大致相似，我以前也从未做过，但最近这方面的开发工作取得了巨大的进展。一方面，实时日志事件对于 MVP 来说可能有点过头了。另一方面，实时渲染日志看起来很漂亮，可以帮助我们提供与命令行一样流畅的用户体验。我们决定尝试一下。

我们最初的计划是使用Prisma Pulse在边缘函数中订阅 Postgres 写入，该函数使用Vercel 流式响应将HiGHS、CBC和SCIP的每行 stdout 发送到浏览器。除了复杂性之外，这个计划还有两个主要问题。找到一个托管的 Postgres 实例，该实例具有合适的表复制功能组合，能够同时满足 Pulse 和我们后端的需求，这并非易事，导致了本文标题前半部分的荒谬之处。两天内五次更换 Postgres 提供商所引发的一系列事件至今仍让我感到震惊。

多米诺骨牌效应始于 Supabase 的 Long（@beertocode）发起挑战。他解释说，他想给使用 Supabase 构建的新人额外的推动力。如果我们在两周内用 Supabase 构建并发布，他们就会利用自己在社交媒体上庞大的粉丝群，让这次发布会更加成功。挑战被接受了，而且确实如此。

在评估数据库选项时，社交媒体机会通常不被考虑。然而，我们的发布目标是收集尽可能多的用户反馈，因此社交媒体是一个不容忽视的因素。我对 Supabase 的产品几乎一无所知，因此花了一个下午的时间阅读了他们的所有文档。到了那天晚上，我对如何构建 IRX 有了完全不同的、更简单的理解。

Supabase 的匿名登录功能加上行级安全机制，意味着用户在 IRX 发布当天无需注册即可使用。这简直是零门槛，在 2024 年那个看似永无止境的“创建账户、重置密码”的循环中，我甚至从未想过这能实现。

匿名登录对我们而言极其宝贵，因为它让近三百人在发布当天就有机会尝试用 IRX 解决混合整数规划问题——即使他们完全不了解 IRX 是什么，只是随便玩玩而已。我们收到了来自不同背景的积极反馈，这远超我的想象。

我们实现实时日志流式传输方法的两个问题中的第二个直到我们实现该功能后才显现出来。Prisma Pulse 限制每个表最多只能有 20 个并发订阅。直到一次资源泄漏瞬间耗尽了我们的整个连接配额，这个限制才显现出来。将并发用户数限制在 20 个显然不利于发布，而且时间紧迫。

当 Long 在三个小时后给我们发推文时，我们还在调试流式传输 😅。幸运的是，此时我已经阅读了所有关于 Supabase 的资料，包括他们的实时事件配额表，该表开箱即用，支持 10,000 个并发客户端。切换过程非常轻松，这主要归功于 Supabase 的 TypeScript类型生成功能。

除了一些背压问题之外，我们还设法为在可能不同的现场实例上同时运行的三个求解器提供实时日志流。

（IRX 内部基础设施图由@baykovr提供）

Long 的说法最准确：

真正疯狂的是，我注册 Resend 是因为他们的 Supabase 集成。他们的创始人@zenorocha在发布前几天就爆红了我们的 Twitter ，一条推文就为我们发布周的流量增加了 1.6 万次浏览量。

以下是我在 IRX 发布当天绘制的基础设施草图：

我们正式启动啦！感谢 Supabase 的挑战！