PlanetScaleが、sharded Postgres をうたう「Neki」をplatform previewとして公開した。単に「Postgresをもっと速くした」と言っているのではなく、1台のマシンの限界にぶつかる前提で、最初から分散運用できる形に作り直した、という話だ。元記事はかなり技術寄りだが、要するに既存のPostgresアプリを大きく壊さずにスケールさせたい人向けの新しい選択肢を出した、というニュースである。しかもPlanetScaleは、これをMySQLで培った分散運用の知見の延長として語っている。
Nekiは、PlanetScaleが公開した sharded Postgres のプラットフォームだ。platform previewとして利用できるようになったが、記事でははっきり「この段階のNekiで本番ワークロードは走らせるべきではない」と注意している。まだ変化が大きく、壊れる変更もありうるからだという。
PlanetScaleによれば、Nekiは同社が8年間かけて運用してきた大規模な sharded MySQL クラスタの経験から生まれた。何千もの本番ワークロード、毎秒何百万クエリという規模、しかも数秒の停止でも大きな問題になるような顧客を支えてきたという。そこにPlanetScale Postgresを出してから1年半が経ち、さらに数千社をオンボードしたものの、Postgresは結局「1台のマシンの天井」に当たりやすい。より大きなインスタンスに移る手はあるが、限界が来るとそれ以上うまく逃がせない。そこでNekiを作った、というのが記事の骨子だ。
Nekiの特徴は、アプリ側から見ると従来のPostgresとかなり近いことにある。アプリは標準の Postgres wire protocol で Neki router に接続し、既存の drivers、ORM、接続文字列をそのまま使える。各 shard は本物のPostgresクラスタで、1つの primary と少なくとも2つの replicas を3つの availability zones にまたがって持つ。独自の storage engine は使わないので、extensions やSQLの挙動、性能特性もPostgresそのものとして扱える。
データの分け方は JSON の data topology で管理する。どの列でshardするか、どのテーブルをどの shard group に置くかを定義し、router がそれを見ながらクエリを振り分ける。router には query parser と distributed query planner があり、どの shard で何を実行するかを判断し、結果をまとめて返す。さらに connection pooling は sidecar が担い、PlanetScaleは「PgBouncer を前に置くだけとは違う」としている。制御系では control plane が各ノードの状態を追跡し、planned switchover や failover、schema change、version upgrade、resharding をまとめて動かす。
興味深いのは、Nekiが「最初から sharded でなければならない」とは言っていない点だ。まずは single primary に replicas を付けた形で運用し、後から sharding したくなったら、今あるクラスタに対して resharding をワークフローとして実行する。PlanetScaleはここでも、運用の手間をアプリではなく基盤側に寄せる姿勢を崩していない。加えて、Insights、schema recommendations、branching、MCP など、PlanetScaleでおなじみの機能もそのまま使えるとしている。
Nekiの説明でいちばん目を引いたのは、分散化そのものより「Postgresを手放さない」と何度も言い切っているところだと思う。分散データベースの世界では、互換性をうたっていても、実際には拡張機能が使えなかったり、挙動差のせいで移行後に調査コストが膨らんだりしがちだ。PlanetScaleはその反省をかなり強く持っているように見える。Nekiは「Postgresっぽいもの」を作るのではなく、各 shard に本物のPostgresを置く。ここはかなり分かりやすい設計思想だ。
この方針は、既存ユーザーにとっては安心材料になりやすい。特にORMやドライバを変えたくない、SQLやextensionの癖もそのまま使いたい、というチームには効くはずだ。一方で、安心感の代わりに「shard key を自分で決める」「data topology を理解する」という責任は残る。完全自動で隠してくれるわけではない。PlanetScaleはそこを隠さず、むしろ明示している。私はこのバランスは健全だと思う。分散の複雑さをゼロにはできないので、どこを自動化し、どこを利用者に持たせるかが重要になるからだ。
Nekiの紹介文は、たしかに魅力的だ。schema change や failover、import、resharding を maintenance window なしで回せる、と読めば、多くのSREやDBAは反応するだろう。ただ、ここで忘れたくないのは、分散Postgresは「楽になる」のではなく、「楽にできる会社の条件が増える」という話でもあることだ。データの偏り、クエリの癖、shard key の設計、どこまで一貫性を求めるか。そういう論点は、結局かなり手前で悩む必要がある。
元記事でも、Nekiは platform preview であり、本番には使うなと明言している。これは単なる注意書きではなく、まだ製品としての確定点が少ないという意味でもあるはずだ。ここを見て「もう単純にPostgresの上位互換が出た」と受け取るのは危ない。むしろ、PlanetScaleがどこまでPostgresの運用を基盤側に吸収できるか、その実験段階が見えてきた、と捉えるほうが正確だろう。
Nekiが刺さる相手は、すでにPostgresが1台の限界に近い、あるいは限界を超えつつあるチームだと思う。巨大なテーブルが vacuum しづらい、バックアップに時間がかかる、接続数が詰まる、schema change のたびに止めたくない。記事が挙げている悩みは、規模が大きくなるほど避けにくいものばかりだ。単純な縦型スケールアップでは解決しきれず、でも application-level sharding は実装も保守も重い。Nekiはその間を狙っている。
ただ、競争相手もかなりはっきりしている。単なる managed Postgres の延長ではなく、分散SQLや互換DB、あるいは自前 sharding の運用ノウハウだ。PlanetScaleは「互換っぽさ」を犠牲にしないことを武器にしているが、そのぶん router、topology、shard group という新しい考え方を受け入れてもらう必要がある。私はここが勝負どころだと思う。便利そうに見えるかどうかより、現場がその新しい運用モデルを学ぶ価値があるかで評価が分かれるはずだ。
PlanetScaleは、MySQLで積み上げた分散運用の経験を、今度はPostgresに持ち込もうとしている。しかも「別物に置き換える」のではなく、Postgresを保ったままスケールさせる方向に寄せているのが面白い。これは単なる新機能の追加ではなく、PlanetScale自身がどの市場で戦うかをかなり明確にした動きだと見える。
同時に、platform preview という段階を考えると、今のNekiは完成品というより方向性の宣言に近い。分散Postgresをどこまで自然に使わせられるか。既存のPostgres利用者に、どこまで違和感なく受け入れられるか。その答えが見えるのは、これからだと思う。
