一个周末搬走 500GB：Shipsidekick 从 Neon 换到 ClickHouse Postgres 的前后对比

Shipsidekick 做仓储、订单和运输管理的 Web 应用，2024 年秋天创立。创始人 Sawyer Bateman 说，以前每到周一就得把 Neon 上的数据库关掉：客户周末积下的订单都在周一发货。¹2026 年 7 月中，他们开始换到 ClickHouse 托管的 Postgres，切换只用了一个周末，之后的周一平平安安。¹

这是 ClickHouse 自己写的客户案例，数字来自 Shipsidekick 的自述。打个折看，它仍然值得参考：用按量计费的云数据库起步，业务长大后撞上连接数和内存的天花板，很多公司迟早会走到这一步。

撑不住的不是数据量，是三层连接池

Shipsidekick 的应用跑在 Vercel 上，数据库是 Serverless Postgres 服务 Neon，ORM 用 Prisma。连接池是一组事先建好、给请求轮流借用的数据库连接；池里的连接全被借走，新请求只能排队，等久了就超时，这叫“池耗尽”。开启 Vercel 的 Fluid compute 后，请求要穿过三层池：Prisma 自带一个；Vercel 要求再建一个 pg 池交给 Prisma，让多个请求共用连接；¹²最外层是 Neon 的 PgBouncer，号称能接 1 万个连接，但不知道和多少用户共用。¹

三层的上限互相牵制。Bateman 说，怎么调都不行：不是 Prisma 的池耗尽，就是 Vercel 的池耗尽；拿掉其中一层，又撞上 Neon 那边 PgBouncer 的上限。数据库的连接数一过 3,000 个左右，必定宕机。¹原文没说这个数是在哪一层统计的。

机器也一直满负荷：到 2026 年年中，Neon 已扩到 16 个计算单元、约 64GB 内存，月费接近 2,300 美元，CPU 常年 100%，缓存命中率只有 30%–35%。故障时提的紧急工单 38 小时后才有回复。¹

迁移前后放在一起，变化最大的是缓存命中率

FIG.1Shipsidekick 迁移前后的核心参数。横条按每行的较大值缩放，虚线条表示查询跑不完。数字都来自 ClickHouse 发布的客户案例，查询时间是一次并排测试。

新库是 16 vCPU、128GiB 内存、3.7TB 存储，只配一个备库：故障切换时可能丢约一秒的写入，换来更低的成本。¹它的存储是和数据库装在同一台服务器上的 NVMe 盘，服务目前还在 beta。³图 1 的变化有三个来源：

连接池从三层变成一层。 新库每台服务器自带 PgBouncer，Shipsidekick 拆掉 Vercel 侧的池直接连它。Shopify 的 webhook 一波能把请求推到每秒 1 万次，真正连到 Postgres 的始终只有 1 到 200 个。¹经 PgBouncer 最多可接 5,000 个客户端。⁴
内存翻倍，热数据装得下了。 缓存命中率从 30%–35% 升到 99%。¹这一项有一部分只是换了台更大的机器，不能全算在新服务头上。
查询变快是前两项的结果。 一个月的货运查询从 1 分 20 秒降到约 6 秒，平均约快 10 倍。¹

降本这一半，原文给得不完整。它只说价格很好，即使按原价也远低于 PlanetScale 每月 4,000 到 5,000 美元的估价，没给新账单。¹内存翻了一倍，新月费未必低于 2,300 美元。能确定的是单位性能的成本降了：差不多量级的钱，买到了不宕机的周一。

搬家只用一个周末，卡住的是一个索引

迁移分两步：先在旧库照常服务的同时把数据复制过去，再找一个周末把流量切过去。

FIG.2第一步，复制：旧库照常服务，约 500GB 用 4–5 小时复制完，之后持续同步到切换。

迁移工具是 ClickPipes，靠 Postgres 的逻辑复制把源库的每次写入按顺序传过去。¹开启前要知道：Neon 会重启所有计算节点，wal_level 改成 logical 后改不回去，复制期间计算节点不会缩到零，账单会涨。⁵ClickPipe 先迁表结构、做并行快照，再用 CDC（变更数据捕获）追新写入。⁴约 500GB 原估一天半，实际 4 到 5 小时。¹

唯一一次卡住：一个定时任务分几个事务写发票表，复制正好赶在它写到一半，撞上了目标库的部分唯一索引。他们删掉索引，复制完再重建；ClickPipes 报错后自动暂停，修好后接着跑，没丢数据。¹指南也写明，CDC 不同步大部分索引和约束，要在切换前手动建好。⁴所以复制前就把唯一索引拿掉、切换前再建，比中途救火稳。

FIG.3第二步，切换：一个周末内把流量切到新库，周日完成。前三步取自 ClickHouse 迁移指南。

切换按指南走：旧库设为只读，核对两边行数，重置序列，再改应用的连接串；旧库保留一段时间，方便回退。⁴Shipsidekick 同时拆掉了 Vercel 侧的连接池，周日完成切换。¹

给 agent 只读权限，也能把主库推到一半 CPU

迁移后还有个插曲。新服务的只读副本目前必须和主库一样大、一样贵，团队就给 AI agent 一个只读角色直接查主库。一个同事的 agent 跑了个查询，几天没人发现，CPU 被推到 40%–50%。现在只读角色加了语句和事务超时，长期打算单独建只读副本。¹

出现这些信号，就该开始评估迁移

应用和数据库之间不止一层连接池，调一层坏一层；
高峰期 CPU 打满，缓存命中率偏低，热数据比内存大；
靠加计算单元续命，月费涨了，性能没跟上；
出故障时，供应商的响应以天计。

这个案例最值得照搬的是做法：连接池收成一层，按热数据大小选内存，复制前拿掉会冲突的索引，切换放在最闲的周末，给 agent 的查询加超时。账单和 10 倍这两个数，要用自己的负载再量一遍。