PlanetScaleとは？無料プラン廃止後の料金（月5ドル〜）とVitess・Postgres・Nekiの違い【2026年11月】

PlanetScaleは、MySQLを水平分割するVitessを土台に始まったマネージドデータベースです。スキーマ変更をGitのブランチのように扱える点で知られ、以前は無料のHobbyプランで個人開発にもよく使われていました。2026年11月時点の姿はかなり違います。無料プランは無くなり、最安の入口はPostgresの単一ノード（月5ドル）になりました。エンジンもMySQL互換のVitessに加えてPostgres、分散Postgresの「Neki」の3系統です。この記事では、東京リージョンでの実際の月額、エンジンの選び分け、Deploy Requestによるスキーマ変更、Vitess由来の制約、そして無料で使いたい人の移行先とデータの持ち出し方まで、公式ドキュメントと公式の料金データで確認した内容を整理します。

まとめ：PlanetScaleの料金・エンジン・採用条件の要点

• 無料プランはありません。Hobbyプランは2024年4月8日に廃止され、現在はセルフサーブのBaseプランと、営業窓口経由のEnterpriseプランの2本です。
• 最安はPostgresの単一ノード（PS-5）で月5ドルです。東京リージョンでも同額でした。ただし単一ノードはSLAの対象外で、3ノードの高可用構成にすると月15ドルからになります。
• MySQL互換のVitessは3ノードのPS-10が最小で、東京は月47ドル、us-east（AWS バージニア北部）は月39ドルです。
• エンジンはVitess（MySQL互換）・Postgres・Neki（分散Postgres）の3系統です。Nekiは2026年11月時点でもPlatform Preview（プレビュー）で、SLAの対象外です。
• ブランチとDeploy Requestによる安全なスキーマ変更はVitessの機能です。Postgresのブランチはdeploy requestを使わず、開発から本番へのスキーマ変更は手作業で写します。
• Vitessでは外部キー制約が非推奨で、シャード化した環境では使えません。ストアドプロシージャやトリガーも使えません。
• 東京リージョンの識別子はap-northeastです。AWSのIDap-northeast-1をそのまま書くと通りません。
• 無料で続けたい場合は、Neon・TiDB Cloud Starter・Tursoのような無料枠のあるサービスへ移すことになります。Vitessのデータはpscale database dump、PostgresとNekiはpg_dumpで持ち出します。

PlanetScaleとは：Vitess・Postgres・Nekiの3系統

PlanetScaleは、YouTubeがMySQLの規模の限界を越えるために作ったオープンソースのVitessを、運用込みで提供する会社として始まりました。Vitessは複数のMySQLの前段でクエリを振り分けるプロキシとして動き、アプリからは1つのMySQLに見えたまま背後を水平分割できます。

2026年時点で「MySQL互換のサービス」とだけ説明するのは不正確です。2025年9月22日にPostgresが一般提供になり、2026年9月10日には分散PostgresのNekiがPlatform Previewとして公開されました。Nekiの詳しい構成と始め方はPlanetScale Nekiとは？シャーディングPostgresの構成・料金・始め方を実装者目線で解説で扱っています。

エンジン3系統の選び分け

選び方の軸は、既存資産とスキーマ変更の運用です。既存のMySQLアプリを持ち込み、レビュー付きのスキーマ変更とリバートを仕組みで強制したいならVitess。新規にPostgresを使い、まず小さく始めたいならPostgres。単一クラスタで足りなくなる規模が見えているPostgresの案件だけNekiを検証する、という順で考えると迷いません。PostgreSQLとMySQLのどちらにするか自体で迷っている場合は、PostgreSQLとMySQLの違いを比較｜同じSQLの実行結果と性能・移行・選び方【2026年版】で先に土台を固めておくと判断が速くなります。

クラウドの選択肢は2026年10月13日に広がり、Azureでも作成できるようになりました。ただし対象はPostgresとNekiだけで、変更履歴に「Vitess databases are not currently available on Azure.」と明記されています。

ネットワーク接続ストレージとMetalの性能・容量・料金比較

もう1つの選択がストレージです。SKU名がPS-で始まるものはネットワーク接続ストレージ（AWSならgp3で、基本性能は3,000 IOPS・125 MiB/s）、M-で始まるものはサーバーに直結したNVMe SSDを使うMetalです。MetalはI/Oの上限に縛られにくい代わりに、ストレージ容量が自動では拡張されません。東京リージョンのMetalの最安は、Nekiが月60ドル、Postgresが月70ドル（M-10 arm64・10GiB込み）、Vitessが月739ドル（M-160）でした。I/Oがボトルネックになっていない段階では、ネットワーク接続ストレージの方が小さく始められます。

PlanetScaleの料金：無料プラン廃止後の最安構成と東京の月額

料金を調べるときは、旧プランの情報と現行プランを分けて読む必要があります。Web上には無料のHobbyプランを前提にした解説がまだ多く残っていますが、公式のプラン説明には「PlanetScale does not offer a free plan, previously known as the “Developer” or “Hobby” plan.」とあり、続けて「Single-node Postgres databases are available starting at $5 per month.」と書かれています。

Hobbyプランの廃止と現在のプラン構成

Hobbyプランは2024年3月6日に新規作成が止まり、2024年4月8日に廃止されました（公式ブログの告知）。現在のプランは、セルフサーブのBaseと、サポート強化や専用環境を選べるEnterpriseの2本です。旧名のScaler ProはBaseへ改称されています。クーポンの仕組みはありますが、同時に有効にできるのは1枚で重ねられません。無料トライアルの有無は公式ページで確認できなかったため、始める時点で支払い情報が要る前提で計画してください。

Baseプランでは本番ブランチが1つ含まれ、追加の本番ブランチは選んだクラスタサイズと同じ月額がかかります。Vitessの開発ブランチは月の時間数の2倍（30日の月で1,440時間）まで追加料金なしです。Vitessのネットワーク接続ストレージは10GBまで含まれ、超過分は1GBあたり月0.50ドル（インスタンスごと）です。PostgresとNekiの超過単価はリージョンなどの条件で異なります。SSOは組織あたり月199ドルの追加です。

東京とus-eastの最小構成の月額

料金ページの既定表示はAWS us-east-1です。PlanetScaleは料金表を読み取り専用のPostgresデータベース（料金SQLカタログ）としても公開しているので、2026年11月6日にpsqlで接続し、東京（ap-northeast-1）とus-east-1の最小構成を照会しました。結果は東京を指定した料金ページの表とも一致しています。

表から読める判断は3つあります。まずPS-5は東京でもus-eastと同額なので、小さな検証は東京で始めて差がありません。次にPS-10以上になると東京はus-eastより2〜4割高く、us-eastの金額で見積もると足りなくなります。最後に、Vitessの非Metal構成にはarm64のSKUが無く、x86-64だけです（料金ページの説明にも「Vitess in this catalog is mostly x86」とあります）。Nekiはこの表のシャード料金に加えてルーター（東京の最小NKR-0で月8ドル）が別にかかります。追加料金はエンジンと構成によって異なります。ストレージ・バックアップ・転送量の課金条件を確認し、Postgresで専用PgBouncerを追加する場合はその料金も見積もってください。

料金SQLカタログは、別リージョンや別クラウドの値を比べたいときに便利です。接続先とパスワードは料金ページのMarkdown版の「Query live prices from Postgres」の節に載っています。2026年11月6日の時点では、同じ節に並ぶURI形式とlibpq形式でパスワードの文字列が違い、libpq形式の方はSASL authentication failedで接続できませんでした。使うならURI形式の方です。

# 料金ページに掲載のURI（読み取り専用）を環境変数に入れておく
export PRICE_DB_URI='postgresql://[email protected]:6432/postgres?sslmode=verify-full&sslrootcert=/etc/ssl/cert.pem'

# 東京とバージニア北部の最小構成を並べる（同じ構成が複数行あるのでDISTINCT）
psql "$PRICE_DB_URI" -c "
SELECT DISTINCT product, machine_sku, replication_factor, region, price
FROM planetscale_prices
WHERE provider = 'AWS'
  AND region IN ('ap-northeast-1', 'us-east-1')
  AND disk_sku = ''
  AND machine_sku IN ('PS-5', 'PS-5-ARM', 'PS-10', 'PS-10-ARM')
ORDER BY product, region, machine_sku, replication_factor;"

macOSのpsqlではsslrootcert=systemが通らないことがあり、その場合は上のように/etc/ssl/cert.pemを指定します。料金ページの説明では、このカタログは「Postgres and Vitess cluster prices」を収めるとされていますが、照会した時点ではNekiとAzureの行も入っていました（Nekiの料金は料金ページの表と同じ値）。

月5ドルの単一ノード構成の本番適用条件とSLA対象外の範囲

月5ドルの単一ノードは、検証用や止まっても困らない用途向けです。PlanetScaleのSLAは単一リージョンのクラスタで月間99.99パーセント、複数リージョンで99.999パーセントを約束していますが、開発ブランチを含む単一ノードのクラスタとベータ機能は対象外です。本番で稼働率を根拠にしたいなら、同じPS-5でも3ノードの月15ドルを選んでください。差額は月10ドルです。

無料で使いたい場合の移行先とデータの持ち出し方

月5ドルを払って残るのも選択肢ですが、無料枠が要件なら移行先は次の3つが現実的です。選ぶときは、今使っているエンジンと移行先の互換性を先に確認してください。上限の値は、いずれも2026年11月6日に各社の公式ページで確認した値です。

PlanetScaleのVitess（MySQL互換）から移すなら、既存SQLの互換性確認を前提として、TiDB Cloud Starterが最も近い移行先です。詳しくはTiDB Serverless（現TiDB Cloud Starter）とは｜東京の料金・無料枠とオートスケールの仕組みで整理しています。PlanetScale Postgresから移すならNeonです。無料枠では5分間アクセスが無いとコンピュートが停止し、この設定は外せません。ブランチは1プロジェクト10本までです（Neonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説）。Tursoは小さなデータを多数のデータベースに分ける用途向けで、MySQLやPostgresからはSQLの方言ごと移すことになります（Tursoとは？料金・使い方とlibSQL/Turso Database（Rust）の違いを実測解説【2026年10月】）。

PlanetScaleからデータを持ち出すコマンド

持ち出し方はエンジンで分かれます。pscale CLIのドキュメントには、pscale database dumpについて「This command is only available for Vitess databases. For Postgres and Neki databases, use the pg_dump command instead.」とあります。

# Vitess（MySQL互換）: ブランチ単位で書き出す。既定の形式はSQL
pscale database dump my-app main --output ./dump-my-app

# 一部のテーブルだけ、またはCSVで書き出す
pscale database dump my-app main --tables users,orders --output-format=csv

# Postgres・Neki: 接続情報を発行してpg_dumpで書き出す
pg_dump "$DATABASE_URL" --format=custom --file=my-app.dump

Vitessのdumpは--columns 'users:id,name'のように列を絞ることもできます。個人情報の列を移行先へ持ち込みたくない場合に使えます。

PlanetScaleの始め方：CLIの導入とデータベース作成

サインアップは公式サイトからGitHubアカウントかメールアドレスで行います。無料枠が無いため、データベースを作る段階で支払い情報を登録します。ダッシュボードだけでも操作できますが、ブランチを日常的に回すならCLIのpscaleを入れた方が速く進みます。GitHubのリリース一覧では、2026年11月5日（日本時間6日）公開のv0.350.0が最新です。2026年10月12日のv0.345.0から数えて6つ目で、版の上がり方が速いので導入時にリリース一覧で確認してください。

# macOS
brew install planetscale/tap/pscale
brew upgrade pscale

# Windows（scoop）
scoop bucket add pscale https://github.com/planetscale/scoop-bucket.git
scoop install pscale mysql

# ログインと、作成できるリージョン・サイズの確認
pscale auth login
pscale region list
pscale size cluster list

エンジンと東京リージョンを指定したデータベース作成

--engineにはmysql（Vitess）、postgresql（postgresも可）、nekiを指定でき、省略するとmysqlになります。Postgresのつもりで--engineを付け忘れるとVitessで作られるので注意してください。

# Vitess（MySQL互換）を東京に作る
pscale database create my-app --engine mysql --region ap-northeast --cluster-size PS-10 --wait

# Postgresを東京に作る
pscale database create my-app-pg --engine postgresql --region ap-northeast --wait

リージョン識別子はAWSのリージョンIDと一致しません。料金ページの対応表では、東京はap-northeast、バージニア北部はus-east、オレゴンはus-west、フランクフルトはeu-centralです。後から追加されたリージョンはaws-us-east-2やaws-ap-southeast-2のようにAWSのIDにaws-が付き、GCPはgcp-asia-northeast3（ソウル）、Azureはazure-eastus2のような形です。命名が揃っていないので、スクリプトに書く前にpscale region listで実際の値を確かめてください。

VitessのDeploy Requestによるスキーマ変更手順

PlanetScaleの中核の機能がここで、Vitessを選んだ場合の話です。開発ブランチは通常、本番のスキーマだけをコピーした作業場所です。変更はDeploy Requestで確認し、レビュー承認を必須にする場合はデータベース設定の「Require administrator approval for deploy requests」を有効にしてから運用します。公式ドキュメントには「Before you can create a deploy request, the branch you are merging into must have safe migrations enabled.」とあり、マージ先でSafe migrationsを有効にしていないとDeploy Request自体を作れません。

# マージ先（main）でSafe migrationsを有効にする
pscale branch safe-migrations enable my-app main

# 開発ブランチを切ってDDLを実行する
pscale branch create my-app add-orders-table --from main --wait
pscale shell my-app add-orders-table
# (MySQLプロンプトで) CREATE TABLE orders (id BIGINT PRIMARY KEY AUTO_INCREMENT);

# 差分を確認し、自動適用を切ってDeploy Requestを作る
pscale branch diff my-app add-orders-table
pscale deploy-request create my-app add-orders-table --into main --disable-auto-apply

# 1は作成されたDeploy Request番号に読み替える
pscale deploy-request deploy my-app 1
pscale deploy-request show my-app 1
# ダッシュボードまたは上の出力で適用可能な状態になったことを確認してから実行
pscale deploy-request apply my-app 1

--disable-auto-applyで作った場合、deployだけでは新しいスキーマに切り替わりません。準備完了を確認してからpscale deploy-request applyを実行して初めて切り替わります。Safe migrationsを有効にしたブランチでは、コンソールやGUIから直接打ったDDLは拒否されるため、スキーマ変更は必ずこの経路を通ります。

30分のリバートと、戻せないインスタントデプロイ

適用後30分間はpscale deploy-request revert my-app 1で元のスキーマに戻せ、その間に元のスキーマへ書き込まれたデータは戻した後も残ります。ただし、追加したテーブルやカラムに書き込まれたデータは、リバートでそのテーブルやカラムごと無くなります。公式ドキュメントは、条件によって孤立した行が残るケースも挙げています。30分を過ぎると変更は確定して戻せないので、適用直後にアプリの主要な読み書きを確認する手順をセットで組んでください。例外がMySQLのALGORITHM=INSTANTを使うインスタントデプロイで、大きなテーブルでも数秒で終わる代わりに、公式ドキュメントの表現では「Instant deployments cannot be reverted and can terminate queries holding locks on the table.」です。カラム追加のように手軽に見える変更ほど、戻せない前提で流すかどうかを判断してください。

PostgresブランチのDeploy Request非対応とスキーマ変更手順

Postgresを選ぶと運用が変わります。Postgresのブランチのドキュメントには「PlanetScale Postgres branches don’t use deploy requests like in Vitess」とあり、各ブランチへ通常のPostgreSQLのDDLを直接流します。さらに「There’s currently no automated way to merge schema changes between PlanetScale Postgres branches.」とあるとおり、開発ブランチの変更は本番へ手で写します。しかもPostgresでブランチを新しく作ると、バックアップから復元する場合を除いてスキーマもデータも入っていない空のデータベースになります。本番のスキーマで試したいなら、2026年8月26日にCLIへ加わった--restore-pointで、指定時刻のバックアップから復元したブランチを作る形になります。「PlanetScaleならスキーマ変更が安全になる」と期待してPostgresを選ぶと、その仕組みは手に入りません。マイグレーションツール側でレビューと適用の手順を用意してください。

Cloudflare WorkersとPlanetScaleの接続・請求連携

2025年9月25日にCloudflareとの公式連携が発表され、Workersからは接続プールとキャッシュを担うHyperdrive経由でつなぎます。2026年6月18日からは、CloudflareのダッシュボードからPlanetScaleのPostgresやMySQLを作り、Cloudflareの請求にまとめられるようになりました。料金はPlanetScaleの標準料金と同じです。CLIで作る場合は、Cloudflareのドキュメントによるとpscale v0.313.0以降で、Wranglerが出す署名を渡します（このWranglerのコマンドは実験的機能です）。

# Cloudflare請求のPostgresをCLIから作る
npx wrangler hyperdrive planetscale signature | \
  pscale database create my-worker-db \
    --org my-org \
    --engine postgresql \
    --cloudflare-billing @- \
    --format json

ここで落としやすいのがキャッシュの一貫性です。Cloudflareのドキュメントには「Hyperdrive does not invalidate cached read results when your application writes to PlanetScale.」とあります。書き込み直後に読み直す認証・セッション・権限のような処理では、キャッシュを無効にした別のHyperdrive設定を用意して読み分けてください。Workers自体の料金や制約はCloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方にまとめています。

Vitess由来の制約：外部キー・非対応機能・シャーディング

一般的なマネージドMySQLと一番違うのがここで、移行できるかどうかを左右します。

Vitessの外部キー制約の非推奨理由と非シャード環境への限定

外部キー制約のドキュメントは「At PlanetScale, we don’t recommend using foreign key constraints.」とした上で、使う場合はSettingsの「Allow foreign key constraints」で有効にするよう案内しています。ただし「Currently, the foreign key constraints are only supported in unsharded environments.」とあり、シャード化した環境では使えません。「今は外部キーを使い、規模が増えたらシャーディングする」という計画はそのままでは成り立ちません。

非推奨の理由として、公式ドキュメントは高並行のワークロードで性能が落ちることと、データベースの複雑さが増すことを挙げています。有効にした後も制限があり、子テーブルへCASCADEやSET NULLが波及する場合のINSERT ... ON DUPLICATE KEY UPDATEなどは未対応です。さらに、Deploy Requestで外部キーを後から足しても、既存の行の参照整合性は検証されません。LaravelやRailsのマイグレーションでは定義や生成方法によって外部キー制約が作られるため、移行前に既存スキーマの外部キーを洗い出し、アプリ側で整合性を守るのか、非シャードのまま有効化するのかを決めておいてください。

PlanetScale VitessのMySQL非対応機能

MySQL互換性のドキュメントで非対応とされている主なものは次のとおりです。

• ストアドプロシージャ、ファンクション、トリガー、イベント（ストアドルーチン全般）
• CREATE DATABASE・DROP DATABASEと、MySQL標準のユーザー・権限管理（作成と権限はダッシュボード・API・CLIで行う）
• LOAD DATA INFILE、JSON_TABLE関数、:=による代入

トリガーで監査ログを書いている、ストアドプロシージャに業務ロジックがある、バッチがLOAD DATA INFILEで大量投入している、という構成は移行時にアプリの作り替えが必要です。MySQL側の前提はMySQLとは？特徴とバージョン選定・採用判断を実装目線で解説【2026年版】で確認できます。

シャーディングに必要な事前情報

シャーディングはどのプランでも使え、ダッシュボードのClustersページからシャードキースペースを追加して移行のワークフローを流します。操作はセルフサービスですが、どの列で分割するかは設計が要ります。公式ドキュメントでは、設計の相談にあたってスキーマ、AUTO_INCREMENTの値などから分かるテーブルの規模、よく使われる50〜100本程度のクエリパターンの3つを求めています。クエリが分割キーをまたぐ設計だと、ここで詰まります。単一クラスタで足りている段階なら、シャード化よりクラスタサイズを上げる方が素直です。分割キーの考え方はシャーディングとは？水平分割の仕組みとシャードキー設計を実装者目線で解説【2026年版】で詳しく扱っています。

Amazon RDS・Aurora・Neonとの比較と採用判断

PlanetScaleを選ぶ理由になるのは、MySQL互換でスキーマ変更の頻度が高く、本番へ直接DDLを打つ経路そのものを塞ぎたい場合です。この強みはVitessでしか効かないので、Postgresを使うならNeonやRDSと比べて「Metalの性能」「Cloudflare請求との統合」「将来Nekiへ広げられること」に価値があるかで判断することになります。AWSの中で完結させたい場合はAmazon RDSとは？仕組み・対応エンジン・料金とAWS CLIでの構築手順を実装者目線で解説やAmazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説が比較の相手です。

採用を見送った方がよいのは次の場合です。無料で始めたい場合。Vitessで、トリガーやストアドプロシージャに業務ロジックを置いている場合。外部キーを維持したままシャーディングまで見込む場合。Postgresを選びながらDeploy Requestのような安全なスキーマ変更を期待している場合。既存のMySQLからの移行や、エンジン選定から一緒に検討したい場合は、データベース設計・移行支援でご相談いただけます。

よくある質問

PlanetScaleに無料プランはありますか？

ありません。無料のHobbyプランは2024年3月6日に新規作成が止まり、2024年4月8日に廃止されました。現在の最安はPostgresの単一ノード（PS-5）で月5ドルです。東京リージョンでも同じ月5ドルでした。

PlanetScaleの料金はいくらからですか？

2026年11月6日に公式の料金データを照会した値では、Postgresの単一ノードが月5ドル、3ノードの高可用構成が月15ドルからです。MySQL互換のVitessは3ノードのPS-10が最小で、東京は月47ドル、us-east-1は月39ドルです。ストレージの超過分・バックアップ・転送量は別にかかります。

PlanetScaleはMySQLですか、PostgreSQLですか？

両方あります。MySQL互換のVitess、PostgreSQLのPostgres、分散PostgreSQLのNekiの3系統で、pscale database createの--engineで選びます。省略するとmysql（Vitess）になります。

東京リージョンは使えますか？識別子は何ですか？

使えます。識別子はap-northeastで、AWSのリージョンIDap-northeast-1ではありません。ほかのリージョンも命名が揃っていないので、pscale region listで確認してから指定してください。

Nekiは本番で使えますか？

2026年11月時点ではPlatform Previewで、SLAの対象外です。組織の管理者がダッシュボードからプレビューに参加して試す段階なので、本番の前提ではなく評価・検証の対象と考えるのが妥当です。

関連記事

• PlanetScale Nekiとは？シャーディングPostgresの構成・料金・始め方を実装者目線で解説
• Neonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説
• TiDB Serverless（現TiDB Cloud Starter）とは｜東京の料金・無料枠とオートスケールの仕組み
• Tursoとは？料金・使い方とlibSQL/Turso Database（Rust）の違いを実測解説【2026年10月】
• シャーディングとは？水平分割の仕組みとシャードキー設計を実装者目線で解説【2026年版】