2026.10.10 データベース

PlanetScale Nekiとは？シャーディングPostgresの構成・料金・始め方を実装者目線で解説

PlanetScale Nekiは、Vitessの開発チームが手がけたシャーディング対応のPostgresです。2026年9月10日にプラットフォームプレビューとして使えるようになり、アプリは1本の接続文字列のまま、複数台に分けたPostgresへ読み書きできます。この記事では、ルーターとシャードの構成、シャードキーを決めるデータトポロジ、pscale CLIでの作成手順、1億1,800万QPSというベンチマークの前提、月額の積み上げ方を整理し、シャーディングに踏み切る条件と見送る場面を示します。

まとめ：PlanetScale Nekiの要点とプレビュー期に試す範囲と待つ範囲の結論

Nekiの中身は「本物のPostgresを何台も並べ、手前のルーターがクエリを振り分ける」構成です。独自のストレージエンジンは持たず、拡張機能やSQLの挙動はPostgresそのもの。シャードキーは利用者が選び、テーブルの配置はデータトポロジというJSON設定で決まります。

2026年10月時点の結論は次のとおりです。本番の業務データは載せません。公式がプレビュー中の本番利用を推奨しておらず、SLAの対象外でもあるためです。一方、単一プライマリの書き込み上限が見え始めた案件なら、今のうちにシャードキー候補を決め、検証用データベースでクエリが1シャードに収まるかを確かめておく価値があります。

まだシャーディングが要らない規模なら、Nekiを検討する前にクエリとインスタンスサイズの見直しを済ませるのが先です。

Nekiの正体：Vitessチームが作った本物のPostgresを束ねる水平分割の基盤

Nekiを一言で言えば「Postgresのためのシャーディング層」。データベースエンジンそのものを新しく作ったわけではありません。

2025年8月の発表から2026年9月10日のプレビュー提供に至るまでの経緯

PlanetScaleがNekiを予告したのは2025年8月11日の発表記事です。このとき示されたのは「Vitessを作ったチームによるシャーディングPostgres」という位置づけと、大規模な設計パートナーと並行して開発している事実まででした。

実際に触れるようになったのは、2026年9月10日公開のIntroducing Nekiから。同日のchangelogには、ルーティング、リシャーディング、オンラインのスキーマ変更、バージョンアップグレードを1本の接続文字列で扱えると記されています。9月18日には拡張機能をTerraformとpscale CLIから管理できる更新も入りました。

Vitessのフォークではなく独自ストレージも持たない設計方針の意味

Vitessは、MySQLを水平分割するためにYouTubeで生まれたOSSです。Nekiは同じチームの作品ですが、公式は「Vitessのフォークではない」と明言しています。MySQLとPostgresではプロトコルも内部構造も違うため、考え方だけを持ち込んで作り直した形です。

実装者にとって効いてくるのは「各シャードが本物のPostgres」という点。Postgres互換をうたう分散データベースでは、拡張機能が使えない、プランナの挙動が本家と違うといった差が出がちです。Nekiは各シャードで素のPostgresを動かすため、単一シャード内のクエリなら既存の知識がそのまま通ります。PlanetScale全体のエンジン構成（Vitess・Postgres・Neki）と料金プランはPlanetScaleの3系統のエンジンと料金の全体像で整理しています。

ルーターとシャードとサイドカーとコントロールプレーンで読むNekiの処理経路

入口は1つでも、裏では役割の違うコンポーネントが分業しています。公式のアーキテクチャ解説に沿って追います。

ステートレスなルーターが3AZに最低3台並んでクエリを振り分ける仕組み

アプリが接続するのはNekiルーターです。Postgresのワイヤプロトコルで話すため、既存のドライバやORMは設定を変えずにつながります。ルーターはクエリを構文解析し、どのシャードで実行するかの計画を立て、複数シャードにまたがる場合は結果を1本にまとめて返します。

ルーターはステートレスで、主ルーターやリーダー選出の仕組みはありません。トポロジとスキーマは各ルーターがローカルにキャッシュします。PlanetScale上では3つのアベイラビリティゾーンに最低3台が置かれ、負荷に応じて台数を増やせる設計です。

1プライマリと2レプリカを3AZに置くシャードとsync耐久性の既定値

各シャードは、プライマリ1台とレプリカ2台以上を3つのAZに分散させたPostgresクラスタです。新しいシャードの耐久性ポリシーは既定でsync。書き込みは少なくとも1台のレプリカが受け取るまで確定しません。

各Postgresの横にはサイドカーが付き、コネクションプーリングと管理操作の窓口を担います。ルーター側とPostgres側の両方をPlanetScaleが握っているため、プールの大きさを各インスタンスの実際の処理能力に合わせて調整できる、というのが公式の説明です。データ移動（リシャーディングやスキーマ変更のコピー）はReplicatorという別コンポーネントがルーターを経由せずに実行します。

フェイルオーバー時にルーターがクエリを保留して再計画するバッファリング

プライマリの切り替え中に届いたクエリは、ルーターが一定時間保留します。計画的な切り替えでは事前に保留の合図が送られ、障害時は特定のエラーをきっかけに保留が始まる。切り替えが終われば、保留していた文を新しいトポロジで計画し直して実行します。

見落としやすいのはディスク不足時の挙動です。容量が尽きかけたシャードは読み取り専用として扱われ、書き込みが拒否されます。アプリ側では、時間切れで返るエラーと書き込み拒否の両方をリトライ方針に組み込んでおく必要があります。

データトポロジJSONで決めるシャードインデックスとシャードグループの設計

Nekiでどのデータがどこに置かれるかは、データトポロジと呼ぶJSON形式の設定が決めます。2026年8月17日の解説記事をもとに、構成要素を順に見ます。

xxhashと剰余と範囲の3方式から選ぶシャードインデックスとルーティングキー

シャードインデックスは「どの列で振り分けるか」と「その値をどう変換するか」の組です。変換方式はハッシュ（xxhash）、剰余、範囲の3つ。変換後の値をルーティングキーと呼びます。

公式の例では、customer_idをxxhashで64ビットのルーティングキーに変換し、シャードグループ内の2台へキー範囲で割り当てています。

customer-shard-1: 0x0000000000000000 through 0x7fffffffffffffff
customer-shard-2: 0x8000000000000000 through 0xffffffffffffffff

customer_id 42 → 0x2e4fe982b68910ac → customer-shard-1
customer_id 1  → 0xf36b4a1a44f78bf3 → customer-shard-2

ハッシュ方式は連番IDでも書き込みが偏りにくい反面、範囲検索は全シャードへ散ります。期間で絞る分析系クエリが主役なら範囲方式も候補に入りますが、新しい期間のデータが1シャードへ集中する偏りとの引き換えです。シャードキー選びの一般論はシャードキー設計と水平分割の仕組みにまとめています。

同じシャードキーのテーブルを同居させJOINとトランザクションを閉じる方法

関連テーブルに同じシャードキーを持たせると、同じシャードへ同居（コロケーション）させられます。こうするとテーブル間のJOINとトランザクションが1シャードの中で完結します。設計の要はここです。

マルチテナントのSaaSなら、テナントを表す列を全テーブルに持たせ、主キーにも含めておきます。

-- 全テーブルにテナントキー（customer_id）を持たせ、主キーにも含める
CREATE TABLE customers (
  customer_id bigint PRIMARY KEY,
  name        text NOT NULL
);

CREATE TABLE orders (
  customer_id bigint NOT NULL,
  order_id    bigint NOT NULL,
  total       numeric(12,2) NOT NULL,
  created_at  timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (customer_id, order_id)
);

-- シャードキーで絞ると1シャードで完結する
SELECT o.order_id, o.total
FROM orders AS o
JOIN customers AS c ON c.customer_id = o.customer_id
WHERE o.customer_id = 42;

-- シャードキーが無い条件は全シャードへ散る
SELECT count(*) FROM orders WHERE created_at >= now() - interval '1 day';

上のSQLは素のPostgresとして書いており、テーブルとシャードインデックスの対応付けはデータトポロジ側で行います。テーブルがシャードグループを指定しない場合は、スキーマ、データベース、クラスタの順に既定値を継承する仕組みです。

シーケンスを置くauthoritativeグループと採番設計で詰まりやすい点

各トポロジにはauthoritativeというグループが1つあり、シーケンスやスキーマ情報などデータベース全体のメタデータを単一シャードで持ちます。公式が採番方式の詳細をまだ書いていないため、ここは検証で確かめるべき箇所です。

実務上の判断としては、シャードキーを連番シーケンスに頼らず、アプリ側で発行するテナントIDや時刻順のUUID系IDに寄せておくほうが安全です。採番の窓口が1か所にあると、書き込みの多い系でそこが詰まる懸念が残るからです。

pscale CLIでNekiのデータベースを作成し接続してスキーマを流すまでの手順

公式クイックスタートに沿い、再現しやすいCLIで手順を示します。

Platform Previewへの参加と組織管理者による規約同意という前提条件

Nekiを選ぶための前提条件は、組織の管理者がプレビューへの参加を済ませていることです。公式ドキュメントの手順では、ダッシュボードの「Join the Platform Preview」か、Organization settingsのPlatform Previewから規約に同意します。同意後、データベースエンジンの選択肢にNekiが現れます。

同じページに、プレビュー中のNekiはベータ機能扱いでSLAの対象外と書かれています。社内の検証用組織と本番の組織を分けておくと、誤って本番データを載せる事故を防げます。

pscale CLIでNekiとPS_10を指定するデータベース作成手順

pscale CLIをインストールして認証を済ませたら、組織とリージョンを確認してから、pscale database createで–engine nekiとPS_10を指定して作成します。

# 組織の確認と切り替え
pscale org list
pscale org switch <ORGANIZATION_NAME>

# 利用できるリージョンのスラッグを確認
pscale region list

# プライマリ＋レプリカ2台のNekiデータベースを作成
pscale database create <DATABASE_NAME> \
  --engine neki \
  --region <REGION_SLUG> \
  --cluster-size PS_10 \
  --replicas 2 \
  --wait

--replicas 2でプライマリに2台のレプリカが付き、最初のシャードはPostgres 3ノードで立ち上がります。新しいデータベースは1シャードで始まり、分割は後から行う流れです。データベース名に使えるのは英小文字・数字・ハイフン・アンダースコアの63文字までで、先頭と末尾に記号は置けません。

pscale shellで接続してテーブル作成とJOINの動作を確かめる手順

接続はpscale shellが手早く、一時的な認証情報を発行してくれるため事前のロール作成は要りません。

# mainブランチへ接続（一時認証情報が自動で発行される）
pscale shell <DATABASE_NAME> main

# 片付け（全ブランチとデータが消える）
pscale database delete <DATABASE_NAME>

プロンプトが出たら、前章のcustomersとordersを作り、シャードキー付きのJOINが返ることを確認します。アプリから継続して使う接続の発行には、ダッシュボードのConnectタブかpscale roleで永続ロールを作る手順が必要です。検証では、本番相当のクエリを流してEXPLAIN ANALYZEで実行計画を読む手順を当て、シャードキーの条件が落ちているクエリを洗い出しておくと、分割後に全シャードへ散るクエリを事前に見つけられます。

1億1,800万QPSのベンチマークを自社の見積もりに使う前に確認する前提

Nekiの紹介で必ず引かれる数字が「1億1,800万QPS」です。数字自体は公式の実測ですが、条件を読まずに転用すると見積もりを誤ります。

512シャードと480ルーターと1.22PiBで計測した読み取り専用の負荷の中身

2026年9月11日のベンチマーク記事によると、512シャードと480台のルーターで118,538,803 QPSを16分間維持しました。データ量は1.22 PiB、各シャードのプライマリはAWSのr8g.16xlargeです。

シャード数	ルーター数	QPS	シャードあたりQPS
5	12	999,624	199,925
50	48	9,923,900	198,478
512	480	118,538,803	231,521

読み取るべきは総量より右端の列です。シャードを100倍に増やしても1シャードあたりの処理量がほぼ落ちていない。ルーター層がボトルネックにならず、シャード数に比例して伸びることを示した結果として見るのが妥当です。レイテンシはルーターのp99が6.06ミリ秒、クライアント側のp99が13.95ミリ秒でした。

レプリカなしの構成とクロスシャード無しという計測条件が示す数字の限界

同じ記事には条件が明記されています。負荷は主キーで1行を取るポイントセレクトだけで、書き込み、JOIN、シャードをまたぐクエリは含みません。シャードはレプリカなしのプライマリ単体で、計測中のフェイルオーバーもありませんでした。

業務システムの見積もりにそのまま当てはめられないのはこのためです。書き込みを含み、sync耐久性でレプリカの受信を待つ本番構成では、1シャードあたりの処理量は別物になります。参考にするなら「単一シャードに閉じる読み取りはシャード数に比例して伸びる」という性質の確認までに留め、自社の負荷は検証環境で測り直してください。

Nekiの料金体系とシャード数とルーター台数から積み上げる月額の計算

Nekiの料金はPlanetScaleの料金ページに、Neki standard、Neki metal、Neki routersの3表で載っています。金額はAWS us-east-1基準の米ドル月額です。

単一ノード構成がなくHA構成の単価にシャード数を掛けて決まるシャード料金

料金ページは「Nekiには単一ノード構成がない」と明記しています。PlanetScale Postgresなら非HAの単一ノードが月5ドルからありますが、Nekiのシャードは常にプライマリ1台＋レプリカ2台のHA単位で課金されます。

計算式は3つです。シャード料金＝HA単価×シャード数。追加レプリカ料金＝追加レプリカ単価×追加台数×シャード数。本番ルーター料金＝ルーター単価×稼働台数÷3。ストレージ、バックアップ、データ転送は別建てで加算されます。

最小構成と4シャード構成の月額試算とストレージや転送の別課金の扱い

公開単価（2026年10月時点）から、2つの構成を試算します。構成欄の数量は、シャード数、ルーター台数の順で示しています。

構成	シャード料金	ルーター料金	月額の目安
PS-10 arm64×1、NKR-0×3台	30ドル	6ドル	36ドル＋ストレージ等
PS-160 arm64×4、NKR-0×3台	1,144ドル	6ドル	1,150ドル＋ストレージ等

PS-10は1/8 vCPU・メモリ1GiBなので、最小構成は動作確認用の位置づけです。本番を見込むなら、シャード単価×シャード数が支配項になる点を押さえてください。シャードを倍にすれば料金もほぼ倍になり、ルーターは高負荷時にNKR-20（月170ドル）以上へ上げる余地があります。分割数を「とりあえず多め」に取ると、そのまま固定費に跳ね返ります。

シャーディングに踏み切る条件とNekiを採用しないほうがよい場面の線引き

Nekiの採否は、製品の出来より「そもそも分割が要るか」で決まります。

公式が挙げる4つの適合シグナルと分割前に試すべき縦方向の拡張策

公式のWhen to shardは、シャーディングが合う状況として次の4つを挙げています。

プライマリが書き込み処理量かディスクIOPSの上限に継続して張り付いている
関連データのワーキングセットが1台のメモリに収まらなくなった
プライマリ障害の影響範囲を、シャードに分けて小さくしたい
テナントIDのように、関連データと頻出クエリを1シャードに束ねられる安定したキーがある

実務で決め手になるのは1と4です。1が無いなら分割は要らず、4が無いなら分割しても全シャードへ散るクエリが増えて遅くなります。公式も、分割に先立つ検討対象として、クエリ改善、スキーマ変更、インスタンスの拡大、ローカルNVMeのMetalを挙げる方針です。AWS上の縦方向の拡張で済むかの比較にはAurora PostgreSQLの構成と移行判断も参考になります。

宣言的パーティショニングでは単一プライマリの書き込み上限を超えられない理由

「まずパーティショニングで」という案はよく出ますが、解く問題が違います。宣言的パーティショニングはテーブルを同じサーバ内で分けるだけで、書き込みを受けるプライマリは1台のまま。公式ドキュメントも、単一プライマリの書き込みボトルネックは解消せず、1台の容量を超えるデータも扱えないと明記しています。

パーティショニングが効くのは、古いデータの切り離しや期間で絞る検索の高速化です。こちらの設計はRANGE・LIST・HASHの使い分けと絞り込み設計で扱っています。書き込み上限が問題ならシャーディング、検索と保守が問題ならパーティショニング、と切り分けてください。

Citus・CockroachDBとNekiの運用形態・互換性による比較

Postgresを水平に広げる手段はNeki以外にもあります。分かれ目は運用形態と互換性の2点です。

Citus：Postgresの拡張機能として分散テーブルを提供するOSS。自前運用やセルフホストが前提ならこちら
CockroachDB・YugabyteDB：Postgres互換の分散SQL。マルチリージョンで強い整合性を求める案件向け
アプリ側シャーディング：ルーティングをアプリのコードで持つ方式。仕組みは単純だが、リシャーディングは全部自前
Neki：マネージド前提で、各シャードは素のPostgres。シャードキーは利用者が選ぶ

Nekiを選ぶのは「マネージドで任せたい」「Postgresの拡張機能や挙動を崩したくない」の両方が当てはまる場合です。マルチリージョンの同期複製が要件なら、CockroachDBの分散SQLの仕組みやYugabyteDBのPostgreSQL互換の範囲のほうが要件に直接答えます。

プレビュー期間中にNekiを本番へ載せない判断と今のうちに進める検証項目

2026年10月時点で、Nekiを本番に入れる判断は取りません。理由は2つ。公式が本番利用を推奨せず破壊的変更を予告していること、そしてSLAの対象外であることです。

それでも待つだけでは損をします。今のうちに進められるのは、シャードキー候補の決定、全テーブルへのテナントキー追加、シャードキー条件の無いクエリの洗い出しの3つ。どれもNeki以外の分割手段を選んだ場合にも無駄にならない作業です。既存PostgreSQLのスキーマ見直しから分割方式の比較、移行計画までを外部と組んで進めるなら、データベース設計・移行支援でシャードキー設計を含めて承っています。

よくある質問

Nekiについて検索されやすい疑問に、判断材料の形で答えます。

NekiとPlanetScale Postgresは何が違いますか？

PlanetScale Postgresは1つのPostgresクラスタ（プライマリ＋レプリカ）を提供するサービスで、書き込みは1台のプライマリが受けます。Nekiはその手前にルーターを置き、データを複数のPostgresクラスタへ分割します。Nekiも最初は1シャードで始まり、必要になった時点で分割する設計です。料金面では、Postgresには月5ドルの単一ノード構成がある一方、Nekiは常にHA構成のみとなります。

Nekiは本番環境で使えますか？

2026年10月時点では推奨されていません。Nekiはプラットフォームプレビューの段階で、公式は本番ワークロードを動かさないよう案内し、破壊的変更の可能性も示しています。ドキュメント上もベータ機能扱いでSLAの対象外です。今の段階では検証用の組織で試し、シャードキーの妥当性やクエリの散り方を確かめる用途に留めるのが安全です。

既存のアプリやORMはそのまま接続できますか？

接続自体はそのままできます。NekiのルーターはPostgresのワイヤプロトコルで話すため、既存のドライバ、ORM、接続文字列の形式を変える必要はありません。ただし性能は別の話です。シャードキーを条件に含まないクエリは全シャードへ散るため、分割前にアプリのクエリを洗い出し、テナントキーで絞れる形へ直しておく必要があります。

NekiはオープンソースのVitessと同じものですか？

別物です。Vitessと同じチームが開発していますが、公式は「Vitessのフォークではない」と明言しています。VitessはMySQL向けのシャーディング基盤で、NekiはPostgres向けに設計し直したものです。また、Vitessはオープンソースとして公開されているのに対し、Nekiは2026年10月時点でPlanetScaleのマネージドサービスとして提供されています。

Nekiの料金は最低いくらからですか？

公開単価で最も小さい構成は、PS-10 arm64のシャード1つ（月30ドル）にNKR-0のルーター3台分（月6ドル）を足した月36ドルが目安です。これにストレージ、バックアップ、データ転送が加算されます。金額はAWS us-east-1基準の米ドル表記で、PS-10は1/8 vCPUのため動作確認用の規模です。本番想定ではシャード単価×シャード数が費用の大半を占めます。