PlanetScaleとは？無料枠終了後の料金・Vitess/Postgres/Nekiの違いを解説【2026年版】

PlanetScaleは、MySQLの分散化技術Vitessを土台に生まれたフルマネージドのデータベースサービスです。データベースのスキーマ変更をGitのブランチのように扱える点で知られてきましたが、2026年時点の姿は当初とかなり違います。無料のHobbyプランは2024年4月8日に終了して有料のみになり、扱えるエンジンもMySQL互換のVitessだけでなくPostgres、さらに分散Postgresの「Neki」へ広がりました。この記事では、現行の料金とプラン構成、東京リージョンでの実際の月額、ブランチとDeploy Requestの運用、Vitess由来の制約、Amazon RDSやNeonとの使い分けまで、公式ドキュメントと公式の変更履歴を確認しながら整理します。

まとめ：PlanetScaleの料金・機能と採用条件（要点先出し）

細部に入る前に、2026年9月時点で押さえておきたい要点を先に並べます。

• 無料枠はありません。Hobbyプランは2024年3月6日に新規作成を停止し、2024年4月8日に廃止されました。現在のセルフサーブは有料のBaseプランのみで、上位にEnterpriseプランがあります。
• エンジンは3系統です。MySQL互換のVitess、Postgres、そして分散Postgresの「Neki」。CLIではpscale database createの--engineでmysql、postgresql、nekiを指定し、既定はmysqlです。
• 東京リージョンのVitess最小構成は、3ノードのPS-10（x86-64）で月額47ドルです。us-east（AWS バージニア北部）では同じPS-10がx86-64で月39ドル、arm64で月30ドルなので、リージョンとアーキテクチャで単価が変わります。
• リージョン識別子はap-northeast-1ではなくap-northeastです。AWSのリージョンIDをそのまま書くと通りません。
• ブランチとDeploy Requestによるスキーマ変更はVitess（MySQL互換）の機能です。公式ドキュメントは「PlanetScale Postgres branches don’t use deploy requests like in Vitess.」と明記しており、Postgresを選ぶとこの運用は使えません。
• Deploy Requestは適用後30分間リバートできます。ただしALGORITHM=INSTANTを使うインスタントデプロイはリバートできません。
• Vitess由来の制約があります。外部キー制約は公式に非推奨で、設定画面で明示的に有効化が必要なうえ、現時点では非シャード環境でのみサポートされます。ストアドプロシージャやトリガー、LOAD DATA INFILEも使えません。
• SLAはシングルリージョンのクラスタで99.99パーセント、マルチリージョンで99.999パーセント。単一ノードのクラスタ、開発ブランチ、ベータ機能は対象外です。

PlanetScaleとは何か：Vitessから3系統へ広がったデータベース基盤

PlanetScaleは、YouTubeがMySQLの規模の限界を越えるために開発したオープンソースのVitessを、フルマネージドのサービスとして提供する会社として出発しました。Vitessは複数のMySQLインスタンスの前段でクエリを振り分けるプロキシとして動き、アプリ側からは1つのMySQLに見えるまま、背後を水平分割できます。PlanetScaleはこの仕組みを運用込みで引き受け、シャーディングやフェイルオーバーを利用者に意識させない形にまとめたサービスです。Vitess自体は現在も活発に開発されており、2026年9月3日にv24.0.3が公開されています。

ただし2026年現在、PlanetScaleを「MySQL互換のサービス」とだけ説明するのは不正確です。2025年9月22日にPlanetScale for PostgresがGA（一般提供）となり、Postgresが正式な選択肢に加わりました。さらに2025年8月11日に発表された分散Postgres「Neki」が、2026年9月10日にプラットフォームプレビューとして利用可能になっています。

Vitess・Postgres・Nekiの選び分け

3系統の違いは、互換性と分散の有無で整理できます。

選ぶ前に押さえておきたいのが、スキーマ変更の運用が系統によって違う点です。PlanetScaleの看板であるブランチとDeploy Requestのワークフローは、Vitess（MySQL互換）の機能です。Postgresでは扱いが変わるため、エンジンの選択はそのまま運用方式の選択になります。詳細は後述のPostgresの節で扱います。

Nekiは公式にVitessのフォークではないと説明されています。VitessはMySQLの長所を活かし短所を設計で回避することで成立しているため、同じ発想をPostgresへ持ち込むにはゼロから設計し直す必要がある、という立て付けです。プレビュー段階なので、組織のダッシュボードのSettings内にあるPlatform Previewから管理者権限でオプトインして試す形になります。既存のMySQL資産を持ち込むならVitess、新規でPostgresを選びたいならPostgres、単一クラスタで足りなくなる規模が見えているならNekiの検証、という順で考えると迷いにくくなります。PostgreSQLとMySQLのどちらを選ぶか自体で迷っている場合は、PostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分け【2026年版】で先に土台を固めておくと判断しやすくなります。

ストレージの選択肢：ネットワーク接続かMetalか

もう一段の選択肢が、データを置く場所です。既定はクラウドのネットワーク接続ストレージですが、2025年3月11日にGAとなったPlanetScale Metalは、サーバーにローカル接続したNVMe SSDを使います。EBSのようなネットワークストレージではIOPSが購入した枠に縛られますが、Metalでは各Mクラスタタイプで無制限のI/Oが使えるとされています。公式の発表では、GA時点で3か月の本番運用を経て5兆クエリ・5ペタバイトを処理し、p99クエリレイテンシが最大65パーセント下がったワークロードがあると説明されています。2025年12月15日にはPostgres向けにM-10、M-20、M-40、M-80の4サイズが追加され、M-10は月額50ドルからになりました。

実務上の判断軸は単純で、I/Oがボトルネックになっているならばやはり検討価値があり、そうでなければネットワーク接続ストレージのほうが小さく始められます。SKU名がPS-で始まるものがネットワーク接続、M-で始まるものがMetalです。

PlanetScaleの料金：Hobbyプラン終了後の有料構成

この記事で最初に確認しておきたいのが料金です。かつてPlanetScaleには無料のHobbyプランがあり、それを前提にした解説が今もWeb上に多く残っていますが、公式の変更履歴には「Our Hobby plan will be retired on April 8th, 2024. As of March 6th, 2024, you are no longer able to create new Hobby databases.」と記載されています。つまり2024年3月6日に新規のHobbyデータベース作成が止まり、2024年4月8日にプラン自体が廃止されました。2026年9月時点で無料プランも無料トライアルも提供されていません。個人の学習用に無料で試す前提で計画を立てると、最初の一歩でつまずきます。

現行プランはBaseとEnterpriseの2本

現在のプラン構成は、セルフサーブのBaseプランと、営業窓口経由のEnterpriseプランの2本です。Baseプランは、フルマネージドのVitess、Neki、Postgresをネットワーク接続ストレージまたはMetalで使えるセルフサーブ型で、シャーディング、ブランチ、クエリインサイトといった機能が含まれます。3つのアベイラビリティゾーンにまたがる構成で、本番ブランチは1つが含まれ、同時接続数に上限は設けられていません。Enterpriseプランは、サポートの強化、機能上限のカスタマイズ、PCI準拠オプションに加えて、PlanetScaleの基盤上で動かすシングルテナント型と、自社のAWSまたはGCPアカウント内で動かすPlanetScale Managedという2つの配置方法を選べます。

Baseプランの周辺費用も押さえておきます。ネットワーク接続のVitessではストレージが10GB含まれ、超過分はインスタンスあたり1GBにつき0.50ドルです。開発ブランチはVitessで約1,440時間（当月の時間数の2倍）が含まれ、超過分は1時間あたり約0.014ドルです。一方でPostgresの開発ブランチは単一ノードのPS-DEVとして作られ、公式ドキュメントの表現では「begins at $5/month, depending on the region」とされています。つまり月5ドルは最低額で、リージョンによって変わります。本番ブランチは3系統とも1つが含まれ、追加分は選択したクラスタサイズと同じ月額がかかります。アドオンとしてシングルサインオン（SSO）が月199ドル、利用者がスケジュールするバックアップが1GBあたり月0.023ドルです。なおクラスタの月額に追加ストレージ・バックアップ・egress・専用PgBouncer・追加レプリカは含まれないため、見積もりではこれらを別立てで足す必要があります。

東京リージョンの実際の月額

料金はリージョンによって変わります。公式の料金ページは既定でAWS us-east-1（バージニア北部）の価格を表示し、クエリパラメータでリージョンを切り替えられます。日本から使う場合は東京（ap-northeast）を指定して確認するのが実態に近くなります。

東京リージョンのVitessはPS-10（1/8 vCPU・1GiB RAM・3ノード）のx86-64が最小で月47ドル、us-east（AWS バージニア北部）のx86-64より2割ほど高く、arm64を選べるus-eastの30ドルとは5割以上の差があります。東京ではarm64のPS-10が提供されていないため、公式ページの既定表示であるus-eastの金額で見積もると足りません。Postgresは単一ノード構成にすると3ノードの約3分の1まで下がりますが、後述するSLAの対象外になる点に注意してください。為替と改定があるため、実際の見積もりは必ず公式の料金ページで対象リージョンを指定して確認することをおすすめします。

アカウント作成からデータベース作成までの手順

ここからは実際の立ち上げ手順です。サインアップは公式サイトから行い、GitHubアカウントとの連携またはメールアドレスで認証します。無料枠が無いため、データベースを作る段階で支払い情報が必要になります。

pscale CLIの導入

ダッシュボードだけでも操作できますが、ブランチやDeploy Requestを日常的に回すならCLIを入れたほうが速く進みます。パッケージ名はpscaleで、2026年9月10日公開のv0.332.0が最新です。macOSはHomebrewのタップから導入します。

# macOS
brew install planetscale/tap/pscale

# 一部のコマンドはPATH上のMySQL 8クライアントを必要とする
brew install [email protected]

# 更新する場合
brew upgrade pscale

Windowsはscoopを使います。Linuxはリリースページのdebまたはrpmを取得してsudo dpkg -iあるいはsudo rpm -iで入れる形です。

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

# コンテナで使う場合
docker pull planetscale/pscale:latest

データベース作成とエンジン・リージョンの指定

ログイン後、データベースの作成はCLIから1コマンドで通ります。ここでエンジンとリージョン、クラスタサイズを明示します。

# ログイン
pscale auth login

# 利用可能なリージョンとクラスタサイズを確認する
pscale region list
pscale size cluster list

# MySQL互換（Vitess）を東京リージョンに作る
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

--engineで指定できる値はmysql、postgresql、nekiの3つで、省略するとmysqlになります。PostgresとNekiでは--major-versionでPostgresのメジャーバージョンを指定でき、省略時は利用可能な最新版が選ばれます。

東京リージョンの識別子とAWSリージョンIDとの違い

ここは実際につまずきやすい箇所です。PlanetScaleはAWSとGCPの両方にリージョンを持ちますが、識別子はAWSのリージョンIDとは一致しません。公式ドキュメントでは東京は「AWS ap-northeast-1 (Tokyo)」の識別子としてap-northeastと記載されています。同様に、バージニア北部はus-east、オレゴンはus-west、フランクフルトはeu-central、ダブリンはeu-westです。一方でシドニーはaws-ap-southeast-2、オハイオはaws-us-east-2のように、後から追加されたリージョンはaws-接頭辞付きでAWSのIDをそのまま使う形になっています。GCP側はgcp-us-central1やgcp-asia-northeast3（ソウル）のようにgcp-接頭辞が付きます。命名が揃っていないので、スクリプトに直書きする前にpscale region listで実際の値を確認するのが確実です。

ブランチとDeploy Requestによるスキーマ変更（Vitess）

PlanetScaleの中核はここです。以下はVitess（MySQL互換）を選んだ場合の話で、Postgresでは扱いが変わります（この章の最後で触れます）。データベースはブランチという単位を持ち、本番ブランチは高可用構成で本番トラフィックを受け、開発ブランチは本番のスキーマを隔離してコピーした作業用の場になります。開発ブランチは既定ではスキーマだけをコピーし、データは含みません。データも含めたい場合はData Branchingという機能を使います。データベースは常に最低1つの本番ブランチを持つ必要があり、本番ブランチを消すには先に降格させるか別のブランチを既定に設定する必要があります。Baseプランに含まれる本番ブランチは1つで、追加は有料です。

Deploy Requestによる本番スキーマへの変更反映

開発ブランチで変更したスキーマは、Deploy Requestを作ってレビューを経てから本番へ入れます。プルリクエストと同じ発想で、差分が提示され、チームが確認してから適用します。ここで先に満たしておく前提が1つあります。公式ドキュメントには「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

# 開発ブランチを切る
pscale branch create my-app add-orders-table --from main --wait

# 開発ブランチへ接続してDDLを実行する
pscale shell my-app add-orders-table
# (MySQLプロンプトで) CREATE TABLE orders (id BIGINT PRIMARY KEY AUTO_INCREMENT);

# 差分を確認する
pscale branch diff my-app add-orders-table

# Deploy Requestを作る（適用は手動で確認してから）
pscale deploy-request create my-app add-orders-table --into main --disable-auto-apply

# 以降の 1 は作成されたDeploy Request番号に読み替える
pscale deploy-request show my-app 1
pscale deploy-request deploy my-app 1

# --disable-auto-apply の場合は、準備完了を確認してから明示的に適用する
pscale deploy-request apply my-app 1

--enable-auto-applyを付ければ準備ができ次第自動で新スキーマへ切り替わりますが、--disable-auto-applyの場合はdeployだけでは切り替えが完了しません。CLIのヘルプにも「Use deploy-request apply to apply the changes manually.」とあるとおり、準備完了を確認したうえでpscale deploy-request applyを実行して初めて新しいスキーマに入れ替わります。--auto-delete-branchを付けると完了後にブランチを自動削除できます。

Safe migrationsの必須条件と30分のリバートウィンドウ

Safe migrationsは、ブランチに対して有効化する保護機能で、前述のとおりDeploy Requestのマージ先では有効化が必須です。有効にしたブランチではスキーマ変更文が直接受け付けられなくなり、公式ドキュメントの表現では「Any CREATE, ALTER, or DELETE commands, whether sent using the PlanetScale built-in console, terminal, or MySQL GUI, will fail when we receive them.」という挙動になります。つまりコンソールからでもMySQLのGUIからでも、スキーマ変更は必ずブランチとDeploy Requestを通す形に強制されます。なお引用中のDELETEは、MySQLの分類では行を削除するDML（DELETE FROM ...）であってDDLではありません。Safe migrationsはスキーマ変更をDeploy Requestへ強制するための機能であり、公式ドキュメントもこの一文以外に通常のデータ書き込みを止めるとは書いていません。とはいえ表記が紛らわしいため、行削除の可否まで運用の前提に置く場合は公式ドキュメントで最新の記述を確認してください。

# Safe migrationsの有効化・無効化（MySQLブランチが対象）
pscale branch safe-migrations enable my-app main
pscale branch safe-migrations disable my-app main

あわせて重要なのがリバートです。Deploy Requestを適用すると、変更後のテーブルへ書き込みが同期され続ける30分のウィンドウが提供されます。この間であれば2つのテーブルの状態を入れ替えて元へ戻せるため、アプリ側との非互換が本番投入後に見つかっても巻き戻せます。逆に言えば、30分を過ぎると同じ手段では戻せません。適用直後にアプリの主要経路を確認する運用をセットで組んでおくのが現実的です。

# 適用済みのDeploy Requestを戻す
pscale deploy-request revert my-app 1

ここに1つ例外があります。MySQLのALGORITHM=INSTANTを使うインスタントデプロイは、通常のオンラインマイグレーションを省略するぶん大きなテーブルでも数秒で完了しますが、リバートできません。加えて短時間のメタデータロックを取り、そのテーブルのロックを保持しているクエリを終了させます。カラム追加や既定値の変更のようにINSTANTが効く変更は魅力的に見えますが、巻き戻せない前提で流す判断になる点は押さえておいてください。

PlanetScale Postgresのスキーマ変更とDeploy Request非対応

設計段階で最も影響が大きい違いがここです。公式ドキュメントは「PlanetScale Postgres branches don’t use deploy requests like in Vitess.」と述べており、Postgresでは各ブランチに対して通常のPostgreSQLのDDLで直接スキーマを変更します。さらに「There’s currently no automated way to merge schema changes between PlanetScale Postgres branches.」とあり、開発ブランチから本番ブランチへの変更は手作業でコピーする必要があります。Postgres側にも開発ブランチと本番ブランチ、バックアップからのブランチ作成やポイントインタイムリカバリはありますが、レビューを経てゼロダウンタイムで適用しリバートする一連の仕組みはVitess側の機能です。「PlanetScaleならスキーマ変更が安全になる」という理解でPostgresを選ぶと、期待していたものが手に入りません。

Vitess由来の制約：外部キーとシャーディング

ここが一般的なマネージドMySQLとの一番大きな違いで、導入判断を左右する部分です。

PlanetScale VitessのMySQL非対応機能

VitessはMySQL 8上で動きますが完全互換ではありません。公式のMySQL互換性ドキュメントで明示的に非対応とされているものに、次があります。

• ストアドルーチン全般。「We do not support any form of stored routines」とされ、ストアドプロシージャ、ファンクション、トリガー、イベントが含まれます。
• CREATE DATABASEとDROP DATABASE。データベースの作成・削除はダッシュボードかAPI、CLI経由で行います。
• CREATE USER。接続情報はPlanetScale側のダッシュボードやAPIで発行します。
• LOAD DATA INFILEによるデータ投入。
• KILLによるクエリ停止と、JSON_TABLE関数。
• SET GLOBAL time_zoneやSET GLOBAL sql_modeによるグローバル設定の変更。
• InnoDB以外のストレージエンジン、および外部レプリケーション向けのバイナリログへのアクセス。

既存のMySQLアプリを移す前に確認すべきはこの一覧です。トリガーで監査ログを書いている、ストアドプロシージャに業務ロジックが入っている、バッチがLOAD DATA INFILEで大量投入している、といった構成は、移行時にアプリケーション側の作り替えが発生します。MySQL側の前提を整理しておきたい場合はMySQLとは？特徴とバージョン選定・採用判断を実装目線で解説【2026年版】もあわせて確認してください。

外部キー制約は非推奨、かつ非シャード環境のみ

PlanetScaleは外部キー制約の利用を推奨していません。公式ドキュメントでは「At PlanetScale, we don’t recommend using foreign key constraints.」とした上で、それでも使いたい場合はデータベースの設定画面から外部キー制約のサポートを有効化できると案内されています。有効化はSettingsタブのGeneralにある「Allow foreign key constraints」にチェックを入れて保存する操作で、ダウンタイムは不要ですが、オープン中のDeploy Requestがあると有効化できません。

さらに重要な限定があります。公式ドキュメントには「Currently, the foreign key constraints are only supported in unsharded environments.」と記載されており、シャード化した環境では外部キー制約を使えません。つまり「今は外部キーを有効化して使い、規模が増えたらシャーディングする」という段階的な計画は、そのままでは成立しません。理由は、高並行のワークロードでの性能、スキーマのリファクタリングの複雑さ、分散環境との相性にあります。

実務上の影響は小さくありません。LaravelやRailsのマイグレーションは外部キーを標準で張る書き方が一般的で、ORMのスキーマ定義をそのまま持ち込むと想定と違う結果になります。移行を検討する際は、既存スキーマの外部キーを洗い出し、アプリケーション側の整合性チェックへ寄せるのか、非シャードのまま設定で有効化するのかを先に決めておく必要があります。

Vitessのシャーディング設計と必要な事前情報

シャーディングはどのプランでも利用でき、ダッシュボードのClustersページからシャードキースペースを追加し、非シャードからシャードへのワークフローを実行します。作成操作自体はセルフサービスで完結しますが、どのキーで分割するかの設計はそうではありません。公式ドキュメントでは、シャーディングの設計にあたってPlanetScale側が3つの情報を求めると説明されています。スキーマのコピー、AUTO_INCREMENTの値などから把握するテーブルサイズの情報、そして最も頻繁に使われる50から100本程度のクエリパターンです。これらをもとにPrimary Vindex（シャーディングキー）を決めるため、アプリケーションを作り直さずにシャード化できるとされています。裏を返せば、クエリパターンが分散に向いていなければ設計段階で詰まります。単一クラスタで足りている段階では、無理にシャード化せずクラスタサイズを上げるほうが素直です。クラスタを増やす方向と1台を強くする方向の使い分けはスケールアウトとスケールアップとは？水平・垂直スケーリングの違いと実装・使い分けを実装目線で解説【2026年版】で整理しています。

PlanetScaleのSLA対象構成と除外条件

可用性の合意は、シングルリージョンのデータベースクラスタで月間99.99パーセント、マルチリージョンのクラスタで99.999パーセントです。ここで見落としやすいのが除外条件で、単一ノードのクラスタ、開発ブランチ、ベータ機能はSLAの対象外とされています。Postgresの単一ノード構成は3ノード構成の約3分の1の価格ですが、価格だけで選ぶとSLAの外に出ます。本番で可用性を根拠にしたい場合は3ノード構成を前提にしてください。

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

他のマネージドデータベースとどう使い分けるかを整理します。

PlanetScaleを選ぶ理由になりやすいのは、スキーマ変更の頻度が高く、その事故を仕組みで防ぎたいケースです。Safe migrationsを有効にすれば本番へ直接DDLを打つ経路自体が塞がれるため、規律を人の注意力に頼らずに済みます。逆にスキーマがほぼ固まっていて変更頻度が低いなら、この強みは効きません。

AWS内で完結させたい場合はAmazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説やAmazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説が比較対象になります。負荷変動が大きく停止時のコストを抑えたいならAmazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説、Postgresでブランチ運用をしたいならNeonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説が近い選択肢です。MySQL互換で水平分割を前提にするならTiDB Serverlessとは｜TiDB Cloud Starterへの改称・料金・オートスケールの仕組みも候補に入ります。

採用を見送ったほうがよい典型を挙げます。全系統に共通するのは、無料で始めたい場合と、日本国内のレイテンシが最優先で東京リージョンの単価差を許容できない場合の2つです。加えてVitess（MySQL互換）を選ぶ場合には、ストアドプロシージャやトリガーに業務ロジックを置いている構成と、外部キー制約を維持したままシャーディングまで見据えたい構成が合いません。これらはPostgresを選べば事情が変わりますが、そのかわりDeploy Requestによるスキーマ変更の仕組みは使えません。いずれも技術的な優劣ではなく前提条件の問題なので、早い段階で切り分けておくと検証の手戻りが減ります。

よくある質問（FAQ）

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

2026年9月時点で無料プランと無料トライアルのいずれも提供されていません。無料のHobbyプランは2024年3月6日に新規作成が停止され、2024年4月8日に廃止されました。現在はセルフサーブのBaseプランが最小の入口で、東京リージョンではVitess・Postgresとも3ノードのPS-10が月47ドルからです。

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

使えます。公式ドキュメントでは「AWS ap-northeast-1 (Tokyo)」に対応する識別子がap-northeastと記載されています。AWSのリージョンIDであるap-northeast-1をそのまま指定すると通らないため、CLIやAPIではap-northeastを使ってください。実際に選べる値はpscale region listで確認できます。

MySQLとPostgresのどちらを選ぶべきですか？

既存のMySQL資産を移すならVitess（--engine mysql）、新規でPostgresを使いたいならPostgres（--engine postgresql）が基本です。ただし決め手になるのはスキーマ変更の運用です。公式ドキュメントは「PlanetScale Postgres branches don’t use deploy requests like in Vitess.」と明記しており、Postgresではブランチ間のスキーマ変更を手作業でコピーします。レビューを経てゼロダウンタイムで適用しリバートするワークフローが目的なら、Vitessを選ぶことになります。

スキーマ変更を間違えたときは戻せますか？

Vitessでは、Deploy Requestの適用後に変更先のテーブルへ書き込みが同期され続ける30分のウィンドウが用意されています。この間であればpscale deploy-request revertで元の状態へ戻せます。ただしALGORITHM=INSTANTを使うインスタントデプロイはリバートできません。30分を過ぎた場合も同じ手段では戻せないため、適用直後にアプリの主要な読み書き経路を確認する運用と組み合わせてください。

外部キー制約は使えますか？

使えますが条件が2つあります。公式には非推奨で、データベースのSettingsタブから明示的に有効化する必要があること、そして「Currently, the foreign key constraints are only supported in unsharded environments.」とあるとおり、シャード化した環境では使えないことです。ORMのマイグレーションが外部キーを標準で張る場合は、そのまま持ち込むと想定と異なる結果になるため、移行前に既存スキーマの外部キーを棚卸ししてください。

既存のMySQLアプリをそのまま移せますか？

完全互換ではないため、事前確認が必要です。公式のMySQL互換性ドキュメントでは、ストアドプロシージャやファンクション、トリガー、イベントといったストアドルーチン全般、CREATE DATABASEとDROP DATABASE、CREATE USER、LOAD DATA INFILE、KILL、JSON_TABLEなどが非対応とされています。ストレージエンジンもInnoDBのみです。これらに依存している箇所はアプリケーション側の作り替えが必要になります。

Nekiは本番で使えますか？

2026年9月10日からプラットフォームプレビューとして提供されています。組織のダッシュボードのSettings内にあるPlatform Previewから、管理者権限でオプトインして利用します。プレビュー段階であり、SLAの除外対象にベータ機能が含まれる点を踏まえると、現時点では本番の前提ではなく評価・検証の対象と位置づけるのが妥当です。

関連記事

• Neonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説
• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説
• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説
• MySQLとは？特徴とバージョン選定・採用判断を実装目線で解説【2026年版】
• TiDB Serverlessとは｜TiDB Cloud Starterへの改称・料金・オートスケールの仕組み