PostgreSQLが遅いとき、分割の前に確認する5項目 — Nekiを検討する入口

PostgreSQLが遅くなったとき、データベースを複数のマシンへ分ける「シャーディング」は選択肢の一つです。しかし、何が詰まっているかを確認する前に分割を決めると、原因を残したまま運用を複雑にする可能性があります。

PlanetScaleは2026年9月10日にNekiを発表しました。PostgreSQLを複数のシャードへ分散し、ルーターが問い合わせを振り分ける構成です。ただし、9月20日時点で確認した公式説明ではplatform previewで、本番ワークロードを動かさないよう明記されています。

まず集める5つの情報

以下は、製品比較の前に整理する診断項目の提案です。必ずこの順に変更すれば直るという手順ではありません。

pg_stat_statementsはSQLの実行統計を調べる手段です。EXPLAINは実行計画を確認する道具ですが、EXPLAIN ANALYZEは実際に文を実行します。重い処理や更新文を、本番で無造作に試さないようにしてください。

特定の検索だけが遅ければ、SQLや索引の見直しが候補です。接続待ちならプール設定を調べます。読み取り負荷の分散が目的なら、レプリカを使えるかを検討します。ただし、レプリカには更新の反映遅延や整合性の要件があります。

使われていないように見える索引を削除する場合も、観測期間が短すぎないか、制約を支えていないかを確認します。データを古いという理由だけで移動しても、対象のクエリが速くなるとは限りません。いずれも、同じ負荷条件で変更前後を測る必要があります。

顧客IDなどで分割すると、同じ顧客に閉じた処理をまとめやすくなる一方、全顧客をまたぐ検索・集計・結合も残ります。分割後にそれらを実行できないとは限りませんが、実行方式や負荷、トランザクションの条件を確認する必要があります。

検討書には、分割キー、偏りの見込み、横断処理、再分割、障害時の復旧、元へ戻す場合の移行計画を残します。「分割は戻せない」と断定するより、戻す費用と手順を事前に見積もる方が判断に役立ちます。

Nekiを評価する場合も、プレビューの環境へ本番データを持ち込む前に、匿名化した代表データと負荷条件で試す計画を作ります。ベンダーの性能値を自社の処理へそのまま当てはめることはできません。

2026年9月20日に公式資料を確認。Nekiの構築やPostgreSQLの性能測定は実施していません。本記事は診断・検証計画の整理です。

データベースのボトルネック調査や構成の見直しは、グリームハブへご相談ください。