ShipsidekickがNeonをClickHouse Managed Postgresに置き換え、クエリを10倍高速化し信頼性を向上させた方法

Sawyer Bateman 氏は、キャリアの大半を出荷や物流について考えることに費やしてきました。2024年秋、Sawyer 氏は新会社 Shipsidekick を立ち上げました。同社は「物流スタックの次のレイヤー」に注力し、荷主や 3PL 向けに倉庫・受注・輸送管理を単一プラットフォームへと統合し、チームの業務管理を支援する AI 相棒(サイドキック)を提供しています。Shipsidekick は Web アプリケーションであり、画面表示、レポート、ユーザーセッションなどをすべて備えています。

「私はデータベースの専門家ではありません」と、Sawyer 氏は 2026年8月にバンクーバーで開催された ClickHouse ミートアップ で参加者に語りました。これは、自称「ジェネラリスト創業者」である同氏とチームが、Neon から移行して ClickHouse Managed Postgres を選定した経緯と、この移行によってクエリが約 10 倍高速化し、データベースの信頼性が大幅に向上したストーリーです。

Neon で直面した課題 #

10年以上前に MySQL 上の Ruby on Rails モノリスで企業を立ち上げた経験を経て、Sawyer 氏はよりモダンなフレームワークを試したいと考えました。同氏は Shipsidekick を Vercel にデプロイする Next.js アプリとして構築しました。当時の一般的な推奨に従い、サーバーレスアプリケーションをサーバーレス Postgres プロバイダーと組み合わせ、Neon に行き着きました。

「Neon は最初のうちは問題ありませんでした」と同氏は振り返ります。しかし、Shipsidekick が Vercel の新しい Fluid compute を有効にしたことで状況は一変しました。このハイブリッドモデルは、アプリケーション側ではより安価で高性能でしたが、Postgres のコネクションプールですぐに問題を引き起こしました。

Sawyer 氏の説明によると、従来のプーリングスタックには 3 つのレイヤーがあり、1 つを修正すると別のレイヤーが壊れる状態でした。Shipsidekick の ORM である Prisma は、独自の内部コネクションプールを保持しています。Vercel は pg プールを作成して Prisma に渡し、Fluid compute セッション間で接続を共有するプラグインにアタッチすることを推奨しています。Neon は 10,000 個のプールされた接続を謳う PgBouncer インスタンスの背後に置かれていますが、「何人のユーザーと共有しているのか分からない状態でした」と Sawyer 氏は話します。

「チューニングには本当に多くの問題がありました」と同氏は付け加えます。「どう工夫しても、プールの枯渇やプールのタイムアウト問題にぶつかりました。Prisma のプールが枯渇するか、Vercel の Fluid プールが枯渇するかのどちらかでした。これらのプールの一部を外すと、PgBouncer の上限に達して Neon からエラーが返ってくる状態でした」

障害の予測は容易になりました。「どうやっても、接続数が 3,000 前後を超えた瞬間にダウンしていました」と同氏は言います。インスタンスの CPU は常に上限に達し、RAM も飽和していました。週末の注文を一斉に出荷する月曜日が、1 週間で最も厳しい日でした。「月曜日に混雑してくると、Neon データベースを毎回停止しなければなりませんでした」

Neon のサポートもほとんど頼りになりませんでした。データベース停止中に提出したある緊急チケットは、38 時間後まで返答がありませんでした。別のチケットでは 6 日かかりました。その間、Neon(2025年に Databricks が買収)からは Databricks Lakebase へのアップグレードを勧めるメールが届き続けました。「技術的な制約もベンダーのサポートも、私たちのニーズを満たしていませんでした」と Sawyer 氏は話します。「ストレスフルな状況を自力で切り抜けなければなりませんでした」

2026年半ばまでに、Sawyer 氏は Neon をオートスケーリング範囲の上限である 16 コンピュートユニット(約 64 GB の RAM)まで引き上げました。「費用はかなりかかっていました」と同氏は語り、月額約 2,300 ドルの請求にもかかわらず、キャッシュヒット率は最大でも 30〜35% にとどまり、読み込みの遅さについて顧客からメールが届いていたと指摘します。「その時点で、新しいソリューションが必要だと判断しました」

ClickHouse Managed Postgres を選んだ理由 #

チームは PlanetScale を評価しました。NVMe 接続のストレージを備えた Metal オファリングは魅力的でした。しかし、PlanetScale の高可用性構成には 2 つのレプリカが必要なため、「実質的に 3 つのデータベース分の料金を支払うことになります」と Sawyer 氏は言います。試算では月額 4,000〜5,000 ドルに達しました。

そんな中、同氏は Hacker News に投稿された ClickHouse の記事 を目にしました。そこには、ClickHouse Managed Postgres において チームが PgBouncer のスループットを 4 倍にスケールさせた方法 が書かれていました。「PgBouncer との格闘に苦しんでいたため、非常に興味深いと感じました」と Sawyer 氏は語ります。

同氏を惹きつけた要因はほかにもいくつかありました。まず、「価格設定が素晴らしかった」と話します。ClickHouse Managed Postgres は PlanetScale よりも多くのインスタンスオプションを提供しており、「CPU、メモリ、ストレージのバランスがまさに適切」でした。同氏が選んだのは、16 vCPU、128 GiB RAM、3.7 TB のストレージ最適化インスタンス(スタンバイ 1 台構成)でした。定価であっても、PlanetScale の試算を大幅に下回っていました。

差額の一部は、ClickHouse が 2 台を要求せず、単一のスタンバイを実行できる点によるものです。「書き込みコミット時のコンセンサスを取る代わりに、スタンバイへ書き込みをストリーミングするだけです」と同氏は説明します。「フェイルオーバーが必要になった場合、1 秒ほどの書き込みが失われる可能性はあります。ですが、費用が 3 分の 1 安くなり、書き込み性能が向上するのであれば許容できます」

もう 1 つの魅力は ドキュメント でした。「ClickHouse が Postgres 向けに用意したドキュメントは信じられないほど素晴らしいです」と Sawyer 氏は言います。「新しい製品とは到底思えません。ドキュメントの内容に誤りや古さは一切なく、迷わされることもありませんでした」

そして、人の存在もありました。製品について調べていた Sawyer 氏は、前職の PeerDB 買収後に ClickHouse Managed Postgres を統括している Sai Srirampur 氏 が、Reddit スレッドで公開の場で質問に答えているのを見つけました。「ClickHouse チームがコメント投稿者とオープンに対話している様子を見て、大きな安心感を得られました」と Sawyer 氏は話します。

「移行プロセスは非常に簡単でした」 #

Sawyer 氏は 7月16日にアカウントを作成しました。同日中に Sai 氏から直接メールが届き、2 時間もしないうちに共有の Slack チャンネルが開設されました。その迅速な対応は嬉しい変化でした。「ClickHouse でダウンが起きても、数秒とは言わずとも数分以内には返答があると確信しています」と Sawyer 氏は言います。

同氏は移行プロセスを「非常に簡単だった」と表現します。チームは ClickHouse の Neon Postgres ソースのセットアップガイド に従いました。Neon 上で論理レプリケーションを有効にし、ClickHouse コンソールの Data Sources パネルから ClickPipe を作成してレプリケーションを実行させるだけでした。当時の Shipsidekick のデータ量は約 500 GB でした。Sai 氏はレプリケーションに 1 日半かかると見積もっていましたが、実際には 4〜5 時間で完了しました。

バンクーバーのミートアップで、Sawyer 氏は同じ手順を進める人に向けて 1 つの注意点を共有しました。アプリケーション内の cron ジョブが複数のトランザクションを実行しており、最終状態ではなく処理途中でレプリケートされたことで、invoices テーブルの部分ユニークインデックスに抵触してしまったのです。「解決策は非常にシンプルでした」と Sawyer 氏は話します。問題のインデックスを削除し、レプリケーションを完了させてから再作成するだけでした。

同氏によると、ClickPipes はこの中断を問題なく処理しました。「レプリケーションでエラーが発生したにもかかわらず、何も失われませんでした」と同氏は言います。「文字通りエラーが解消されるまで待機し、何事もなかったかのようにすべてが再開されました」

もう 1 つの検討事項はコネクションプーリングでした。Shipsidekick のトラフィックは本質的にスパイクが発生しやすい性質を持っています。Shopify の Webhook が押し寄せると、アプリのリクエストは毎秒 0 件から 10,000 件へと跳ね上がることがあります。Vercel 上では、それぞれが独自のプールを持つ多数のファンクションインスタンスが立ち上がることになります。Sawyer 氏はサーバーレス環境向けの PgBouncer 設定方法を ClickHouse チームに相談しました。結果として、設定するものは何もないことがわかりました。ClickHouse Managed Postgres は すべてのサーバーに PgBouncer インスタンスを同梱している ため、Shipsidekick は Vercel 側のプールを撤廃し、直接接続するようにしました。「端的に言って、まったく問題ありませんでした」と Sawyer 氏は言います。

クエリが 10 倍高速化し、CPU 使用率は 90〜95% 削減 #

週末にカットオーバーを行いたかったため、移行作業は日曜日に完了しました。かつて 1 週間で最もストレスフルだった月曜日が訪れ、そして過ぎ去りました。「まったくの静寂でした」と同氏は話します。

効果はすぐに現れました。ClickHouse Managed Postgres 上での CPU 使用率は、通常 5〜10% で推移しています。「Neon で常時 100% に張り付いて苦しんでいたのを見てきた後では、信じられないほどの改善です」と Sawyer 氏は言います。実際の Postgres データベースへの接続数は、常に 1〜200 件の間に収まっています。

「ClickHouse Managed Postgres の PgBouncer は、Vercel 上で何が起きても見事に吸収してくれます。スパイクの多いリクエストの抑制を試みる必要すらなくなりました。まったく問題ありません。キャッシュヒット率が 30〜35% から 99% へと跳ね上がったのも大きな成果でした」

— Sawyer Bateman 氏(Shipsidekick 創業者兼 CEO)

キャッシュヒット率の大幅な向上と、ネットワーク接続ストレージではなく高速なローカルディスクにデータを保持する ClickHouse Managed Postgres の NVMe 接続ストレージ の組み合わせにより、性能は劇的に改善しました。「クエリ時間は劇的に短縮されました」と Sawyer 氏は言います。

同氏は、負荷がゼロのまま維持されていた以前の Neon インスタンスとの並行比較テストを実施しました。1 か月分の出荷データ(約 50 万行)の取得には、Neon で 1 分 20 秒かかりましたが、ClickHouse では約 6 秒で完了しました。Neon では完了すらしなかった 2 か月分のデータも、ClickHouse では 20 秒で返ってきました。「平均して Neon より 10 倍高速であり、ベストケースでは無限に速いとすら言えます」と同氏は言います。「Neon は半分くらいの確率で全く動きませんでしたから」

AI エージェントとリードレプリカ #

Neon を利用していた際、Shipsidekick は小型で安価なリードレプリカを運用し、すべての AI エージェントや MCP サーバーから接続させていました。ClickHouse Managed Postgres のリードレプリカは現在、プライマリと同じサイズ(および料金)に合わせる必要があるため、Sawyer 氏は当初リードレプリカの追加を見送り、代わりにプライマリ上でエージェントに読み取り専用ロールを付与しました。「少しの間は問題ありませんでした」と同氏は話しますが、チームメンバーのエージェントが実行したクエリがツール呼び出しの奥深くに埋もれ、数日間気づかれないまま CPU 使用率を 40〜50% まで押し上げる事態が発生しました。「これを見て目が覚めました。AI による読み取りはプライマリのパフォーマンスに影響を与える可能性があると気づいたのです」

これを防止するため、チームは読み取り専用ロールにステートメントタイムアウトとトランザクションタイムアウトを設定しました。長期的な対策としては、エージェント専用のリードレプリカを用意することにしました。

顧客満足度の向上と、さらなる分析の導入へ #

移行後、Sawyer 氏は ClickHouse の他の用途も模索しています。エージェントはログ、Postgres の統計情報、スロークエリデータにアクセスできるため、チームはすでにパフォーマンス調査に ClickHouse Agents を活用しています。「次のアクションや改善策を検討する上で、素晴らしい壁打ち相手になっています」と同氏は言います。

また同氏は、どのワークロードを ClickHouse 本体に移すべきかもエージェントに相談しており、Shipsidekick のアプリ内ダッシュボードがその自然な最初の候補となっています。「アプリケーション内にダッシュボードがありますが、処理が遅い状態です」と Sawyer 氏は話します。同社の分析ニーズが Postgres のキャパシティを超えて拡大するにつれ、チームはその移行をスムーズに進められる態勢を整えています。「移行で非常にうまく機能してくれたため、ClickPipes には大きな信頼を寄せています」と同氏は付け加えます。「実際に ClickHouse の活用を本格化する際、何を使うべきかは明白です」

Shipsidekick にとって最も重要なのは、顧客がアプリケーションをどのように体感するかです。Sawyer 氏は、ClickHouse Managed Postgres への移行から数日後、以前読み込みの遅さについてメールしてきたのと同じ顧客と交わした会話を振り返ります。「『何をしたのかは分からないけれど、アプリがすごく速くなった』と言われました。私は『何をしたかは分かっています。Neon をやめたんです』と答えました」

毎週の障害と何日も待たされるサポート対応から、週末での移行、そして最も混雑する日すら平然と捌くデータベースへの転換は、Shipsidekick にとってまさに大きな転換点となりました。

「ClickHouse と Postgres を一緒に管理できるこの統合プラットフォームを心から気に入っています。すべてが高速で、顧客も満足しており、私たちも非常に満足しています」

— Sawyer Bateman 氏(Shipsidekick 創業者兼 CEO)