--- title: "PlanetScaleとは？無料プラン廃止後の料金（月5ドル〜）とVitess・Postgres・Nekiの違い【2026年11月】" url: "https://www.issoh.co.jp/tech/details/7819/" published: 2025-07-22 updated: 2026-11-06 categories: ["データベース"] publisher: "株式会社一創" --- # 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のID`ap-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として公開](https://planetscale.com/changelog/neki)されました。Nekiの詳しい構成と始め方は[PlanetScale Nekiとは？シャーディングPostgresの構成・料金・始め方を実装者目線で解説](/tech/details/18225/)で扱っています。 ### エンジン3系統の選び分け | エンジン | 互換先 | 水平分割 | 単一ノード | 提供状況（2026年11月） | | -------- | ---------- | ---- | --------- | ------------------------------ | | Vitess | MySQL | 対応 | なし | 一般提供・AWSとGCP | | Postgres | PostgreSQL | なし | あり（月5ドル〜） | 一般提供・AWS・GCP・Azure | | Neki | PostgreSQL | 対応 | なし | Platform Preview・AWS・GCP・Azure | 選び方の軸は、既存資産とスキーマ変更の運用です。既存のMySQLアプリを持ち込み、レビュー付きのスキーマ変更とリバートを仕組みで強制したいならVitess。新規にPostgresを使い、まず小さく始めたいならPostgres。単一クラスタで足りなくなる規模が見えているPostgresの案件だけNekiを検証する、という順で考えると迷いません。PostgreSQLとMySQLのどちらにするか自体で迷っている場合は、[PostgreSQLとMySQLの違いを比較｜同じSQLの実行結果と性能・移行・選び方【2026年版】](/tech/details/6262/)で先に土台を固めておくと判断が速くなります。 クラウドの選択肢は2026年10月13日に広がり、[Azureでも作成できるようになりました](https://planetscale.com/changelog/planetscale-on-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](https://planetscale.com/docs/metal)です。MetalはI/Oの上限に縛られにくい代わりに、ストレージ容量が自動では拡張されません。東京リージョンのMetalの最安は、Nekiが月60ドル、Postgresが月70ドル（M-10 arm64・10GiB込み）、Vitessが月739ドル（M-160）でした。I/Oがボトルネックになっていない段階では、ネットワーク接続ストレージの方が小さく始められます。 ## PlanetScaleの料金：無料プラン廃止後の最安構成と東京の月額 料金を調べるときは、旧プランの情報と現行プランを分けて読む必要があります。Web上には無料のHobbyプランを前提にした解説がまだ多く残っていますが、[公式のプラン説明](https://planetscale.com/docs/planetscale-plans)には「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日に廃止されました（[公式ブログの告知](https://planetscale.com/blog/planetscale-forever)）。現在のプランは、セルフサーブの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の最小構成を照会しました。結果は[東京を指定した料金ページ](https://planetscale.com/pricing.md?region=ap-northeast)の表とも一致しています。 | 構成 | SKU | us-east-1 | 東京 | | ----------------- | ------------- | --------- | ----- | | Postgres 単一ノード | PS-5（x86・arm） | 月5ドル | 月5ドル | | Postgres 3ノード（HA） | PS-5（x86・arm） | 月15ドル | 月15ドル | | Postgres 3ノード（HA） | PS-10 arm64 | 月30ドル | 月41ドル | | Vitess 3ノード | PS-10 x86-64 | 月39ドル | 月47ドル | | Neki 1シャード（3ノード） | PS-10 arm64 | 月30ドル | 月41ドル | 表から読める判断は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版](https://planetscale.com/pricing.md)の「Query live prices from Postgres」の節に載っています。2026年11月6日の時点では、同じ節に並ぶURI形式とlibpq形式でパスワードの文字列が違い、libpq形式の方は`SASL authentication failed`で接続できませんでした。使うならURI形式の方です。 ``` # 料金ページに掲載のURI（読み取り専用）を環境変数に入れておく export PRICE_DB_URI='postgresql://...@aws-us-east-1-3.pg.psdb.cloud: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](https://planetscale.com/legal/planetscale-service-level-agreement)は単一リージョンのクラスタで月間99.99パーセント、複数リージョンで99.999パーセントを約束していますが、開発ブランチを含む単一ノードのクラスタとベータ機能は対象外です。本番で稼働率を根拠にしたいなら、同じPS-5でも3ノードの月15ドルを選んでください。差額は月10ドルです。 ## 無料で使いたい場合の移行先とデータの持ち出し方 月5ドルを払って残るのも選択肢ですが、無料枠が要件なら移行先は次の3つが現実的です。選ぶときは、今使っているエンジンと移行先の互換性を先に確認してください。上限の値は、いずれも2026年11月6日に各社の公式ページで確認した値です。 | サービス | エンジン | 無料枠の主な上限 | | ------------------ | -------------- | ------------------------------ | | Neon | PostgreSQL | 100プロジェクト・1プロジェクト1GB・月100 CU時間 | | TiDB Cloud Starter | MySQL互換 | 組織あたり5インスタンス・各5GiB・月5,000万RU | | Turso | SQLite（libSQL） | 100データベース・5GB・月5億行読み取り | PlanetScaleのVitess（MySQL互換）から移すなら、既存SQLの互換性確認を前提として、[TiDB Cloud Starter](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)が最も近い移行先です。詳しくは[TiDB Serverless（現TiDB Cloud Starter）とは｜東京の料金・無料枠とオートスケールの仕組み](/tech/details/7541/)で整理しています。PlanetScale Postgresから移すなら[Neon](https://neon.com/docs/introduction/plans)です。無料枠では5分間アクセスが無いとコンピュートが停止し、この設定は外せません。ブランチは1プロジェクト10本までです（[Neonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説](/tech/details/16444/)）。Tursoは小さなデータを多数のデータベースに分ける用途向けで、MySQLやPostgresからはSQLの方言ごと移すことになります（[Tursoとは？料金・使い方とlibSQL/Turso Database（Rust）の違いを実測解説【2026年10月】](/tech/details/12088/)）。 ### PlanetScaleからデータを持ち出すコマンド 持ち出し方はエンジンで分かれます。[pscale CLIのドキュメント](https://planetscale.com/docs/cli/database)には、`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のリリース一覧](https://github.com/planetscale/cli/releases)では、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」を有効にしてから運用します。[公式ドキュメント](https://planetscale.com/docs/vitess/schema-changes/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のブランチのドキュメント](https://planetscale.com/docs/postgres/branching)には「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との公式連携](https://planetscale.com/changelog/cloudflare-integration)が発表され、Workersからは接続プールとキャッシュを担うHyperdrive経由でつなぎます。2026年6月18日からは、[CloudflareのダッシュボードからPlanetScaleのPostgresやMySQLを作り、Cloudflareの請求にまとめられる](https://developers.cloudflare.com/changelog/post/2026-06-18-planetscale-databases-cloudflare-billing/)ようになりました。料金はPlanetScaleの標準料金と同じです。CLIで作る場合は、[Cloudflareのドキュメント](https://developers.cloudflare.com/hyperdrive/planetscale/)によると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の中身と対応言語・使い方](/tech/details/6760/)にまとめています。 ## Vitess由来の制約：外部キー・非対応機能・シャーディング 一般的なマネージドMySQLと一番違うのがここで、移行できるかどうかを左右します。 ### Vitessの外部キー制約の非推奨理由と非シャード環境への限定 [外部キー制約のドキュメント](https://planetscale.com/docs/vitess/foreign-key-constraints)は「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互換性のドキュメント](https://planetscale.com/docs/vitess/troubleshooting/mysql-compatibility)で非対応とされている主なものは次のとおりです。 - ストアドプロシージャ、ファンクション、トリガー、イベント（ストアドルーチン全般） - `CREATE DATABASE`・`DROP DATABASE`と、MySQL標準のユーザー・権限管理（作成と権限はダッシュボード・API・CLIで行う） - `LOAD DATA INFILE`、`JSON_TABLE`関数、`:=`による代入 トリガーで監査ログを書いている、ストアドプロシージャに業務ロジックがある、バッチが`LOAD DATA INFILE`で大量投入している、という構成は移行時にアプリの作り替えが必要です。MySQL側の前提は[MySQLとは？特徴とバージョン選定・採用判断を実装目線で解説【2026年版】](/tech/details/13135/)で確認できます。 ### シャーディングに必要な事前情報 シャーディングはどのプランでも使え、ダッシュボードのClustersページからシャードキースペースを追加して移行のワークフローを流します。操作はセルフサービスですが、どの列で分割するかは設計が要ります。公式ドキュメントでは、設計の相談にあたってスキーマ、`AUTO_INCREMENT`の値などから分かるテーブルの規模、よく使われる50〜100本程度のクエリパターンの3つを求めています。クエリが分割キーをまたぐ設計だと、ここで詰まります。単一クラスタで足りている段階なら、シャード化よりクラスタサイズを上げる方が素直です。分割キーの考え方は[シャーディングとは？水平分割の仕組みとシャードキー設計を実装者目線で解説【2026年版】](/tech/details/16274/)で詳しく扱っています。 ## Amazon RDS・Aurora・Neonとの比較と採用判断 | サービス | エンジン | スキーマ変更の扱い | 無料枠 | | ------------- | --------------------- | --------------------------------- | ------------ | | PlanetScale | MySQL互換・Postgres・Neki | Deploy Requestと30分のリバート（Vitessのみ） | なし | | Amazon RDS | MySQL・PostgreSQLほか | 通常のDDL | AWSの無料利用枠に依存 | | Amazon Aurora | MySQL互換・PostgreSQL互換 | 通常のDDL | AWSの無料利用枠に依存 | | Neon | PostgreSQL | コピーオンライトのブランチ | あり | PlanetScaleを選ぶ理由になるのは、MySQL互換でスキーマ変更の頻度が高く、本番へ直接DDLを打つ経路そのものを塞ぎたい場合です。この強みはVitessでしか効かないので、Postgresを使うならNeonやRDSと比べて「Metalの性能」「Cloudflare請求との統合」「将来Nekiへ広げられること」に価値があるかで判断することになります。AWSの中で完結させたい場合は[Amazon RDSとは？仕組み・対応エンジン・料金とAWS CLIでの構築手順を実装者目線で解説](/tech/details/15426/)や[Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説](/tech/details/15447/)が比較の相手です。 採用を見送った方がよいのは次の場合です。無料で始めたい場合。Vitessで、トリガーやストアドプロシージャに業務ロジックを置いている場合。外部キーを維持したままシャーディングまで見込む場合。Postgresを選びながらDeploy Requestのような安全なスキーマ変更を期待している場合。既存のMySQLからの移行や、エンジン選定から一緒に検討したい場合は、[データベース設計・移行支援](/service/system/database/)でご相談いただけます。 ## よくある質問 ### 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のリージョンID`ap-northeast-1`ではありません。ほかのリージョンも命名が揃っていないので、`pscale region list`で確認してから指定してください。 ### Nekiは本番で使えますか？ 2026年11月時点ではPlatform Previewで、SLAの対象外です。組織の管理者がダッシュボードからプレビューに参加して試す段階なので、本番の前提ではなく評価・検証の対象と考えるのが妥当です。 ## 関連記事 - [PlanetScale Nekiとは？シャーディングPostgresの構成・料金・始め方を実装者目線で解説](/tech/details/18225/) - [Neonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説](/tech/details/16444/) - [TiDB Serverless（現TiDB Cloud Starter）とは｜東京の料金・無料枠とオートスケールの仕組み](/tech/details/7541/) - [Tursoとは？料金・使い方とlibSQL/Turso Database（Rust）の違いを実測解説【2026年10月】](/tech/details/12088/) - [シャーディングとは？水平分割の仕組みとシャードキー設計を実装者目線で解説【2026年版】](/tech/details/16274/) --- 出典: [PlanetScaleとは？無料プラン廃止後の料金（月5ドル〜）とVitess・Postgres・Nekiの違い【2026年11月】]()（株式会社一創）