Shipsidekick 用 ClickHouse Managed Postgres 替代 Neon，查询快10倍

Sawyer Bateman 职业生涯的大部分时间都在思考运输和物流。2024 年秋天，Sawyer 创办了他的新公司，Shipsidekick。该公司专注于“物流技术栈的下一层”，将仓库、订单和运输管理整合到一个面向托运人和第三方物流（3PL）的单一平台中，并配备一个 AI 助手来帮助团队管理运营。Shipsidekick 是一个 Web 应用，包含随之而来的所有界面、报表和用户会话。

“我不是搞数据库的，”Sawyer 在 2026 年 8 月在温哥华举行的 ClickHouse 聚会上对听众说。这是一个关于一位自称“通才创始人”的人及其团队如何选择 ClickHouse Managed Postgres、从 Neon 迁移出来，以及这次迁移如何使查询速度提升约 10 倍、数据库可靠性大幅提高的故事。

Neon 带来的挑战

十多年前，Sawyer 曾在 MySQL 上使用 Ruby on Rails 单体架构创办公司，积累了经验之后，他想尝试更现代的框架。他将 Shipsidekick 构建为部署在 Vercel 上的 Next.js 应用。遵循当时的标准建议，他为这个无服务器应用搭配了一个无服务器 Postgres 提供商，最终选择了 Neon。

“Neon 在一段时间内还不错，”他说。然而，当 Shipsidekick 启用 Vercel 新的 Fluid 计算后，情况发生了变化。这种混合模式在应用侧更便宜、性能更好，但立即引发了 Postgres 连接池的问题。

Sawyer 解释说，旧的连接池技术栈有三层，修复一层只会破坏另一层。Shipsidekick 的 ORM Prisma 维护着自己的内部连接池。Vercel 希望您创建一个 pg 连接池，将其传递给 Prisma，并附加到一个插件上，以便在 Fluid 计算会话之间共享连接。Neon 位于一个 PgBouncer 实例之后，该实例宣称有 10,000 个池化连接，“但他们在我们不知道有多少人之间共享它，”Sawyer 说。

“我们在调优方面遇到了大量问题，”他补充道。“无论我们怎么切分，最终都会遇到连接池耗尽和连接池超时问题……我们要么是 Prisma 连接池耗尽，要么是 Vercel fluid 连接池耗尽。如果我们去掉其中一些连接池，就会因为触及 Neon 的 PgBouncer 限制而收到来自 Neon 的错误。”

故障变得很容易预测。“无论怎样，我们一超过大约 3,000 个连接就会宕机，”他说。实例始终受 CPU 限制，RAM 也达到饱和。周一，当客户处理周末的订单发货时，是一周中最艰难的一天。“我们不得不在每个周一的繁忙时段关闭我们的 Neon 数据库。”

Neon 的支持几乎帮不上忙。一张在数据库宕机时提交的紧急工单，直到 38 小时后才得到回复。另一张花了六天。与此同时，Neon（于 2025 年被 Databricks 收购）不断发邮件建议 Shipsidekick 升级到 Databricks Lakebase。“技术限制和供应商支持都无法满足我们的需求，”Sawyer 说。“我们不得不独自应对许多充满压力的局面。”

到 2026 年中期，Sawyer 已将 Neon 扩展到其自动扩缩容范围的上限，即 16 个计算单元（约 64 GB RAM）。“我们花了很多钱，”他说，并指出即使账单接近每月 2,300 美元，他们的缓存命中率最高也只有 30-35%，而且客户还在发邮件抱怨加载速度慢。“那时，我决定我们需要一个新的解决方案。”

他们为什么选择 ClickHouse Managed Postgres

他们评估了 PlanetScale，其提供 NVMe 存储的 Metal 方案很有吸引力。但 PlanetScale 的高可用设置需要两个副本，所以“你本质上是在为三个数据库付费，”Sawyer 说。他的估算约为每月 4,000-5,000 美元。

然后他看到了 ClickHouse 在 Hacker News 上的一篇帖子。帖子展示了 团队如何将 PgBouncer 的吞吐量扩展到 4 倍，在 ClickHouse Managed Postgres 中。“因为我们一直在和 PgBouncer 较劲，所以我觉得这非常有意思，”Sawyer 说。

还有几件事吸引了他。首先，他说，“价格非常棒。”ClickHouse Managed Postgres 还提供了比 PlanetScale 更多的实例选项，“CPU、内存和存储的搭配恰到好处”。他选择了 16 vCPU、128 GiB RAM、3.7 TB 存储优化型实例，并配有一个备用节点。即使按全价计算，也远低于他对 PlanetScale 的估算。

部分差异在于 ClickHouse 允许你运行单个备用节点，而不需要两个。“他们不是在提交写入时进行写入共识，而是直接将写入流式传输到备用节点，”他解释道。“如果必须故障切换，也许会丢失一秒的写入。对此我可以接受，换来的是成本降低三分之一和写入性能提升。”

另一个吸引人的地方是 文档。“ClickHouse 为 Postgres 整理的文档非常出色，”Sawyer 说。“这感觉不像是一个新产品。文档中没有任何不正确、过时或误导我们的内容。”

然后是人。在研究产品时，Sawyer 发现了一个 Reddit 帖子，其中 Sai Srirampur（在其前公司 PeerDB 被收购后领导 ClickHouse Managed Postgres）正在公开回答问题。“看到 ClickHouse 团队与评论者公开交流，”Sawyer 说，“这给了我们很大的信心。”

“迁移过程非常简单”

Sawyer 于 7 月 16 日创建了账户。Sai 当天亲自给他发了邮件，几个小时内他们就进入了共享的 Slack 频道。这种响应速度是一个可喜的变化。“我毫不怀疑，如果我们的 ClickHouse 出现故障，我们会在几分钟甚至几秒钟内得到响应，”Sawyer 说。

他称迁移过程“非常简单”。团队遵循了 ClickHouse 的 Neon Postgres 源设置指南：在 Neon 上启用逻辑复制，从 ClickHouse 控制台的 Data Sources 面板创建 ClickPipe，然后让它复制。当时 Shipsidekick 有大约 500 GB 的数据。Sai 估计复制需要一天半。结果花了四五个小时。

在温哥华的聚会上，Sawyer 指出了一个任何走同样路线的人都会遇到的波折。应用中的一个 cron 任务运行了多个事务，这些事务在复制过程中被复制的是中途状态而非最终状态，从而触碰了 invoices 表上的一个部分唯一索引。“解决方案非常简单，”Sawyer 说：删除有问题的索引，让复制完成，然后重新创建它。

ClickPipes，他指出，优雅地处理了这次中断。“尽管复制过程中出现了错误，但它没有丢失任何东西，”他说。“它实际上只是等待直到错误被解决，然后一切就像什么都没发生一样继续下去。”

另一个悬而未决的问题是连接池。Shipsidekick 的流量本质上具有尖峰特性。一波 Shopify webhook 可以使应用从每秒零请求飙升到每秒 10,000 个请求。在 Vercel 上，这意味着要启动许多函数实例，每个实例都有自己的连接池。Sawyer 向 ClickHouse 团队询问如何在无服务器环境中配置 PgBouncer。结果发现根本没有什么需要配置的。ClickHouse Managed Postgres 为每个服务器捆绑了一个 PgBouncer 实例，因此 Shipsidekick 移除了 Vercel 的连接池，直接连接到它。“长话短说，这不成问题，”Sawyer 说。

查询速度提升 10 倍，CPU 使用率降低 90-95%

迁移在周日完成，因为 Sawyer 想在周末进行切换。周一，这一周中最令人紧张的一天，来了又走了。“就像蟋蟀一样安静，”他说。

他们立刻看到了好处。在 ClickHouse Managed Postgres 上，CPU 使用率通常保持在 5-10%。“在目睹它在 Neon 上 24/7 挣扎于 100% 之后，看到这个真是太棒了，”Sawyer 说。与实际的 Postgres 数据库的连接数在任何时候都徘徊在一到 200 之间。

“ClickHouse Managed Postgres 的 PgBouncer 非常出色地吸收了 Vercel 上发生的一切。我们甚至不必费心去控制尖峰请求的特性。这完全没问题。缓存命中率是一个巨大的胜利，从 30-35% 提升到了 99%。” — Sawyer Bateman，Shipsidekick 创始人兼 CEO

在缓存命中率的跃升和 ClickHouse Managed Postgres 的 NVMe 支持的存储（将数据保存在快速的本地磁盘而非网络附加存储上）之间，性能简直是天壤之别。“我们的查询时间急剧下降，”Sawyer 说。

他对旧的 Neon 实例进行了并排测试，该实例仍然处于配置状态但零负载。拉取一个月的货运数据（大约 500,000 行）在 Neon 上花了一分二十秒，而在 ClickHouse 上大约 6 秒。两个月的数据在 Neon 上根本无法完成，而在 ClickHouse 上 20 秒就返回了。“平均而言，它比 Neon 快 10 倍，而在最好的情况下，似乎无限快，”他说，“因为一半的时间里 Neon 根本就不会工作。”

AI 代理与只读副本

在 Neon 上，Shipsidekick 有一个小型、廉价的只读副本，其所有 AI 代理和 MCP 服务器都指向它。ClickHouse Managed Postgres 中的只读副本目前必须与主库的大小（和价格）匹配，因此 Sawyer 最初跳过了一个，转而给代理在主库上分配了一个只读角色。“有一段时间这没问题，”他说，直到团队中某人的代理运行了一个查询，该查询被埋在一个工具调用中，几天都没被发现，将 CPU 推高到 40-50%。“我当时想，好吧，敲响了警钟。你的 AI 读取可能会影响你的主库性能。”

为了防止这种情况，他们在只读角色上实现了语句和事务超时。长期的解决方案是为代理设置一个专用的只读副本。

客户更满意，更多分析即将到来

自迁移以来，Sawyer 一直在探索还可以用 ClickHouse 做什么。团队已经在使用 ClickHouse Agents 进行性能调查，因为代理可以访问日志、Postgres 统计信息和慢查询数据。“它是一个极好的帮手，帮助我们决定下一步做什么以及如何改进，”他说。

他还一直在询问代理哪些工作负载应该迁移到 ClickHouse 本身，Shipsidekick 的应用内仪表板自然是第一个候选。“我们的应用中有仪表板，但它们很慢，”Sawyer 说。随着公司的分析需求超出 Postgres 的能力，团队已经做好了进行这一迁移的充分准备。“我现在对 ClickPipes 非常有信心，因为它在迁移中表现得太好了，”他补充道。“当真正开始使用 ClickHouse 的时候，我们将选择谁就显而易见了。”

对于 Shipsidekick 来说，最重要的是应用给客户的感受。Sawyer 回忆起在迁移到 ClickHouse Managed Postgres 几天后与同一位曾发邮件抱怨加载缓慢的客户的一次对话。“他们说，‘我不知道你做了什么，但应用现在很快。’我说，‘我知道我做了什么。我们摆脱了 Neon。’”

从每周停机和支持等待数天，到周末迁移和一个几乎察觉不到其最繁忙日子的数据库，对 Shipsidekick 来说，这是一个相当大的转变。

“我们很喜欢这个统一的平台，同时管理 ClickHouse 和 Postgres。一切都很快，客户很开心，我们也是。” — Sawyer Bateman，Shipsidekick 创始人兼 CEO