ハクソク

世界を動かす技術を、日本語で。

Neki – シャーディッドPostgres

2026年9月11日原文(planetscale.com)

概要

Neki は、PlanetScaleが提供する シャーディング対応Postgres の新サービス。 Postgresデータベースを 複数マシンに分散 しながら、標準のPostgres機能を維持。 既存のドライバやORM がそのまま利用可能。 スキーマ変更やリシャーディング などの運用もオンラインで完結。 現在は プラットフォームプレビュー として提供中、本番利用は非推奨。

Nekiとは何か

  • Neki はPlanetScaleが開発した シャーディング対応のPostgresサービス
  • 複数のマシン にデータベースを分散し、 各シャードが本物のPostgresクラスタ
  • Postgres標準のワイヤプロトコル で接続、既存のドライバやORMをそのまま利用可能
  • 各シャードは 1つのプライマリ と 最低2つのレプリカ を3つのアベイラビリティゾーンに分散配置
  • カスタムストレージエンジンは不使用、Postgresの拡張機能やSQL互換性・パフォーマンスを維持
  • JSON形式のデータトポロジー でシャードキーやテーブルの分散方法を柔軟に設定
  • スキーマ変更、バージョンアップ、フェイルオーバー、リシャーディング などをオンラインで実現
  • PlanetScaleの既存機能 （Insights、スキーマ推奨、ブランチング、MCP等）も利用可能
  • 初日からシャーディング不要、単一プライマリ＋レプリカ構成からスムーズにスケールアウト可能

Nekiが解決する課題

  • 急成長Postgresデータベース にありがちな課題
    • テーブル肥大化による VACUUMやインデックス作成の遅延
    • バックアップ時間の増大
    • 接続数制限 の問題
    • スキーマ変更やメンテナンスに伴うダウンタイム
    • トランザクションラップアラウンド 等のスケーラビリティ問題
  • 大規模インスタンスにスケールアップ しても限界がある
  • 既存の解決策 （アプリケーションレベルシャーディングや互換DB）は
    • コードへのルーティング実装負荷
    • 拡張機能やSQL互換性の制限
    • 複雑性やレイテンシ増大
  • NekiはPostgresの本来の機能を最大限活用 し、妥協のないスケーラビリティを実現

Nekiのアーキテクチャ

  • Neki Router
    • アプリケーションは Neki Router に接続
    • Postgresワイヤプロトコル対応、既存の接続文字列をそのまま利用
    • クエリパーサ・分散クエリプランナー・バッファリング 機能を搭載
    • クエリ解析→実行シャード決定→結果集約までを一貫して処理
    • 垂直・水平スケーリング 可能、ボトルネック回避
  • シャーディングとシャードグループ
    • 各シャードは本物のPostgres、拡張機能やパラメータを個別に設定可能
    • シャードグループ単位でテーブルやワークロードを分離
    • インスタンスサイズやレプリカ数、ストレージ容量等を グループごとに最適化
  • コネクションプーリング
    • 各Postgresインスタンス横にSidecar を配置
    • Neki独自のプーリング で、PgBouncer以上に効率的な接続管理を実現
    • RouterとPostgres双方を制御 し、インスタンス能力に応じたプール調整
  • コントロールプレーン
    • ノードのヘルスチェック、計画的スイッチオーバー・フェイルオーバーを実施
    • リシャーディングやスキーマ変更、バージョンアップ 等のワークフローを統括
  • データトポロジー
    • JSON設定で論理テーブルと物理シャードをマッピング
    • シャードインデックス（ルーティングカラムやハッシュ方法）や シャードグループ（テーブル分散先とシャード数）を指定
    • Routerはトポロジーをキャッシュし、クエリごとに参照

Nekiのオンライン運用機能

  • 全てのメンテナンス作業がオンラインワークフロー
    • 新ノードのプロビジョニング、レプリケーションによるキャッチアップ
    • __nekiメタファンクションによるトラフィックスイッチ、旧ノードのリタイア
    • psql接続のまま一貫した操作
  • スキーマ変更、バージョンアップ、フェイルオーバー、インポート、リシャーディング をオンラインで実施
  • PlanetScaleの既存機能 （Insights、スキーマ推奨、ブランチング、MCP等）も利用可能
  • 未シャーディング状態でも高機能
    • コネクションプーリング、オンラインDDL、ゼロダウンタイムアップグレード、ヘルス監視
    • 必要になった時点で 既存クラスタに対してリシャーディング実行

プラットフォームプレビューについて

  • Nekiは現在プラットフォームプレビュー
    • 本番運用は非推奨、仕様変更や互換性破壊の可能性あり
    • フィードバックや質問はサポートチケットまたはDiscordで受付
  • PlanetScaleにサインインし、プラットフォームプレビューに参加するとNekiクラスタ作成可能
  • Nekiドキュメント でアーキテクチャやシャーディング方法を確認可能
  • 大規模Postgresクラスタを運用中の場合、個別デモや設計相談も可能

Hackerたちの意見

みんな、ローンチ投稿では何を立ち上げているのか、そしてそれが何のためなのかを説明するのを忘れないでね。理想的には冒頭の段落で。

  • イントロ: 問題は説明してるけど、Nekiが何なのか、何のためなのかは言ってない。
  • Nekiの理由: 代替案を説明してるけど、Nekiが何なのか、何のためなのかは言ってない。
  • Nekiの仕組み: 技術的な要素を説明してるけど、Nekiが何なのか、何のためなのかは言ってない。
  • シャーディング以外に得られるもの: 実行やデプロイの仕方を説明してるけど、Nekiが何なのか、何のためなのかは言ってない。
  • プラットフォームプレビューとは何か + 今日Nekiを試してみて: 「プレビュー」の定義について140語と、始めるためのリンクがあるけど、Nekiが何なのか、何のためなのかは言ってない。 編集: ランディングページには100倍役立つ情報が載ってるよ -> https://neki.dev/ 編集 #2: その後、「Nekiとは何か」のセクションが追加されたね。反応が早い。
└

このページの2文目の最初にリンクされてるランディングページ…？君の言ってることには完全には反対しないけど、これは主にハイパーテキストが意図通りに機能してるってことじゃない？

└

みんな、君たちのブログ記事はマーケティングがダメだね。追記：君たちのマーケティングサイトには実際に素晴らしいマーケティング情報があるよ。追記#2：その後、ブログ記事がマーケティングページへのリンクに置き換えられたね。反応が早いな。

いやー、このブログ記事を読み進めてるうちに「Nekiって何？」って質問に答えるのがやっとだったよ。

└

https://neki.dev/ はNekiの概要がもっと簡潔に書かれてるよ。

└

3文目か4文目までに内容がわからなかったら、スキップしちゃう。空っぽな言葉は空っぽな頭から出てくるし、そんなのに時間はかけられないから。

これを見るのは嬉しいけど、ヘビーユーザーとしてはPlanetScaleの分散にちょっと不安があるな。Vitessの改善が続くことを願ってるよ。自己中心的な疑念は置いといて、PlanetScaleのローンチおめでとう！

└

心配しないで、まだビテスにもたくさん愛を注いでるよ。結局、どっちもデータベースだからね。両方やることで、それぞれの製品から学んだことを他に活かせるのがいいんだ。

今、Nekiの広告が貼られた12番のバスに乗ってるんだけど、さっき10分前にneki.devを調べてこの製品が何なのか見てみたんだ。このバス広告のリリースはローンチ日と合わせてるのかな？

└

バス広告はちょっと前から流れてるよ。他にもいくつかビルボードがあるね。

HA分散Postgres（例えばRDS Auroraグローバル）を提案したときに、開発チームから一番の懸念として聞いたのは、最終的な整合性が多くのワークロードには適していないってこと。Nekiはこれを解決するの？もしそうなら、どうやって？CAP定理の理解では、これは基本的に可用性に関していくつかの妥協が必要なんだけど、実際にはどうなってるのか気になるな。

└

彼らのMySQL製品、Vitessと同じように動くと仮定すると: 通常の運用方法は、ユーザーのような何かに基づいてDBをパーティション分けすることなんだ。そうすれば、単一のユーザーには一貫したDBが提供されるけど、シャードを跨いだものはそうじゃないかもしれない。Blockで働いてたとき、CashappがVitessを使ってて、シャードを跨いだDB書き込みがうまくいかないのが採用の大きな障害の一つだったんだ。（ただ、私はVitessのTLS管理だけしてて、上にワークロードを書いてなかったから、印象がちょっと違うかもしれないけど。）

Hacker Newsで議論の続きを見る