TiDB Serverlessとは｜TiDB Cloud Starterへの改称・料金・オートスケールの仕組み

TiDB Serverlessは、PingCAPが提供するMySQL互換の分散SQLデータベース「TiDB」を、インフラ管理なしで使えるフルマネージド形態で提供するサービスです。重要な変更として、2025年8月12日に名称が「TiDB Cloud Starter」へ改められました。「tidb serverless」で検索して公式サイトに進むと、現在は「TiDB Cloud Starter」という名前のページに着きます。本記事では、この改称で何が変わり何が変わらないのか、オートスケールの仕組み、RU課金と無料枠の実数、MySQL互換移行、ベクトル検索、Aurora Serverlessとの違いまでを最新仕様で整理します。

まとめ：改称後の全体像と要点

• 名称変更：TiDB Cloud Serverless は 2025年8月12日に TiDB Cloud Starter へ改称。接続文字列・エンドポイント・データはそのままで、アプリの改修もダウンタイムも不要。
• プラン構成：無料から始める Starter、固定容量（RCU）でSLAを担保する Essential、専有クラスタの Dedicated の3系統。
• 課金：Starterはリクエストを RU（Request Unit）、ストレージを GiB 単位で従量課金。無料枠はインスタンスあたり行5GiB＋列5GiB＋50M RU／月、組織で最大5インスタンス。
• オートスケール：コンピュートとストレージを分離し、負荷に応じてSQL処理ノードを自動増減。アイドル時は課金が発生しない。
• AI対応：ベクトル検索と全文検索を標準搭載し、RAG・チャットボットの基盤として1つのSQLで扱える。

TiDB Serverlessとは｜2025年に「TiDB Cloud Starter」へ改称

TiDBは、コンピュート層とストレージ層を分離した分散アーキテクチャを持つNewSQLデータベースで、MySQL 8.0互換のSQLをそのまま使いながら水平スケールできる点が特徴です。TiDB Serverless（現・TiDB Cloud Starter）は、このTiDBをサーバーレス形態で提供し、クラスタのサイズ設計やノード管理を利用者が行わずに使えるようにしたものです。トランザクション処理（OLTP）と分析処理（OLAP）を同一DBで扱えるHTAP構成を、無料枠から試せます。

「Serverless」から「Starter」へ改称された理由と影響

PingCAPは、「serverless」という語が抽象的で初めての利用者に用途が伝わりにくいことを理由に、エントリープランの名称を「Starter」へ変更しました。2025年8月12日（PDT）以降、既存のTiDB Cloud Serverlessクラスタはコンソール上で自動的に「Starter」と表示されます。接続文字列・エンドポイント・保存済みデータは変更されないため、稼働中アプリのコード修正や再接続は不要です。技術的な中身はServerless時代と同一で、変わったのは呼び名とプラン整理だけ、と理解して差し支えありません。

Starter・Essential・Dedicatedの3プランと選び方

改称にあわせて上位プラン Essential が加わり、選択肢が整理されました。用途別の目安は次の通りです。

トラフィックが読みにくく小さく始めたいならStarter。処理量が安定し、常時一定の性能とSLAが要るならEssential（後述のとおり最小2,000 RCU＝月額目安$400前後から）。専有環境や高度な運用機能が必要ならDedicated、という順で検討すると迷いにくいです。

オートスケールの仕組みとRU課金モデル

「tidb オートスケール」で流入するニーズの核心は、何を単位に、どう自動で増減するのかです。TiDB Cloud Starterは、コンピュート（SQL処理）とストレージを分離し、リクエスト状況に応じてSQL処理ノードを動的に増減します。利用者はノード数やインスタンスサイズを設定せず、実際に消費したRU（Request Unit）とストレージ容量に対してのみ支払います。アイドル状態では課金が発生しないため、常時稼働型のプロビジョニングと比べて無駄が出にくい構造です。

コンピュートとストレージを分離した内部構成

TiDBのアーキテクチャは役割の異なる4コンポーネントで構成されます。各コンポーネントの分担とRegion単位の複製、HTAPの内部動作はTiDBとは？MySQL互換の分散SQLの仕組みと採用判断の解説で詳述しています。

TiDBノードはステートレスなので、リクエストごとに起動・スケールできます。データはTiKVがリージョン単位で分割保持し、各リージョンは通常3レプリカを持ち、Raftコンセンサスでリーダーが書き込みを担当します。ノード障害時はPDが検知して即座にリーダーを切り替えるため、整合性を保ったまま処理を継続できます。列指向のTiFlashを併せ持つことで、同じデータに対しトランザクションと分析クエリを別途ETLせずに実行できるのがHTAPの利点です。

RU（Request Unit）で計測する自動スケール

Starterはリクエストの消費量を RU に抽象化して計測します。SELECT・INSERT・UPDATEなどの読み書きがRUを消費し、消費量に応じてバックエンドが処理能力を自動調整します。公開エンドポイント経由のデータ転送は 1KiBあたり1RU が加算される点も把握しておくと、コスト見積もりがぶれません。広告配信やリリース直後のスパイクでも、手動でノードを足す作業なしにスケールする一方、RUは実消費に連動するため「使った分だけ」という課金の明快さが保たれます。

TiDB Cloud Starterの料金体系と無料枠

「tidb 料金」「tidb free tier」で最も知りたいのは無料枠の具体的な上限と、超過後の単価です。ここは旧情報が出回りやすい箇所なので、最新の実数で押さえます。

無料枠：インスタンス5GiB＋50M RU、組織で最大5インスタンス

Starterの無料枠は 1インスタンスあたり 行データ5GiB＋列データ5GiB＋月間50M RU です。無料インスタンスは組織あたり最大5つまで作成でき、合計すると 行25GiB＋列25GiB＋月間250M RU までを無料で使えます。無料枠はサインアップ直後から自動適用され、申請は不要です。6つ目以降のインスタンスや無料枠の超過にはクレジットカード登録と月間上限（spending limit）の設定が必要になります。

従量課金の単価とEssential（RCU固定）との違い

無料枠を超えると従量課金へ切り替わります。標準的な米国リージョンでは 100万RUあたり$0.10、行ストレージ$0.20／GiB・月 が基準です。東京・シンガポール・フランクフルトなどのプレミアムリージョンは割増単価となるため、日本リージョンで使う場合は公式の料金表で最新単価を確認してください。上位のEssentialは従量ではなく RCU（Request Capacity Unit）を固定でプロビジョンするモデルで、最小2,000 RCU（AWSオレゴンでデータ料金前に月額$400前後）から。安定負荷でSLAを重視するならEssential、変動が読めずコストを実消費に連動させたいならStarter、という住み分けです。

コストを抑える設計ポイント

RUは読み書き量に比例するため、コスト最適化はクエリ設計に直結します。インデックス未使用の全表走査や不要なJOIN・サブクエリを減らすことがそのままRU削減になります。ストレージは圧縮やアーカイブ、アクセス頻度の低いデータの分離で抑えられます。ダッシュボードでRU消費とストレージ使用量を可視化できるので、上限アラートを設定して超過を予防するのが現実的です。日本語圏で本番運用するなら、プレミアムリージョンの割増を前提に月間上限を保守的に設定しておくと想定外の請求を避けられます。

MySQL互換性と既存データベースからの移行

TiDB Cloud Starterは MySQL 8.0互換を基準に設計され、SELECT・INSERT・UPDATE・DELETEなどのDML、DDL、インデックス、トランザクション制御を同等に扱えます。既存のMySQLクライアントやORM、接続ドライバがそのまま使え、移行時のコード改修を抑えられます。

互換範囲と非対応機能

一方で、ストアドプロシージャ・トリガー・ユーザー定義関数（UDF）はいずれも非対応で、特定のストレージエンジンに依存する処理も挙動が異なります。これらをMySQL側で多用している場合はアプリ側のロジックへ寄せる設計変更が要るため、移行前にスキーマとSQLを公式の互換性ガイドと突き合わせて棚卸しするのが安全です。接続はSSL/TLSが前提で、証明書の取得・設定が必要になる場合があります。

移行ツールとスキーマ設計の注意点

PingCAPは、MySQLからのエクスポートに Dumpling、TiDBへのインポートに TiDB Lightning を提供しています。移行後はChecksumでデータ整合性を検証します。設計面では、連番のオートインクリメント主キーを多用するとリージョンにホットスポットが生じスループットが落ちやすいため、UUIDやSnowflake系IDなど分散に強いキー設計が推奨されます。なお、StarterではTTLジョブの実行間隔が15分固定で変更できないなどの制約があるため、期限付きデータの設計時は考慮しておきます。既存DBを止めずに移すなら、非クリティカルなテーブルから段階移行し、並行稼働で検証してから切り替えるのが定石です。

ベクトル検索・全文検索によるRAG実装

TiDB Cloud Starterは、ベクトル検索と全文検索を標準搭載しています。埋め込みベクトルをテーブルに直接保存し、SQLで類似度検索を実行できるため、FaissやPineconeのような専用エンジンを別立てせずにRAG（Retrieval-Augmented Generation）構成を組めます。生成AIアプリでは、LLMから得た埋め込みをそのまま格納し、ユーザーの質問に近いナレッジを取り出してコンテキストを補完する流れを、1つのDB・1つのSQLインターフェースで完結できます。全文検索と組み合わせれば、意味的な近さとキーワード一致を併用したハイブリッド検索も構築できます。ベクトル検索とキーワード/セマンティック検索の使い分けはベクトル検索とセマンティック検索の違いで整理しているので、設計前に押さえておくと選定がぶれません。トランザクションと分析・検索を同一DBで扱えるHTAP特性が、この用途では効いてきます。

Aurora Serverless・Cloud Spannerとの比較

サーバーレス型DBの比較検討では、Amazon Aurora ServerlessやGoogle Cloud Spannerが候補に挙がります。特性の違いを整理します。

スモールスタートで無料から検証したい、MySQL資産を活かしたい、トランザクションと分析・ベクトル検索を1つのDBで扱いたい、というケースではStarterが噛み合います。既にAWSでMySQL/PostgreSQL資産が厚くAurora中心で固めたい場合はAmazon Aurora Serverless v2の料金・スケーリングの仕組みと比較したうえで選ぶとよいでしょう。

始め方：アカウント作成から接続まで

Starterはブラウザだけで数分で始められます。手順は次の通りです。

• 公式サイト（tidbcloud.com）でメールアドレスまたはGoogle/GitHub/Microsoftアカウントによりサインアップする。
• クラウドプロバイダとリージョンを選び、Starterインスタンスを作成する（クラスタ構成は自動、容量設定は不要）。
• ダッシュボードに表示される接続情報（ホスト・ポート・ユーザー・パスワード）とSSL設定を確認する。
• MySQLクライアントやDBeaver、DataGrip等から接続する。ブラウザ上のSQLコンソールからもクエリを実行できる。

MySQL互換なので、接続コマンドも既存の書き方がそのまま使えます。

mysql --connect-timeout 15 -u '<user>.root' -h '<host>' -P 4000 -D test --ssl-mode=VERIFY_IDENTITY -p

導入前に知っておくべき制約と向かない場面

Starterは共有型のエントリープランのため、Essential/Dedicatedにはない制約があります。設計段階で確認すべき主な上限は次の通りです。

これらから、Starterを避けるべき場面は明確です。数十分に及ぶ長時間トランザクションを多用するバッチ処理、監査ログやCMEKがコンプライアンス要件になる金融・医療系、他システムへ変更をストリーミングするChangefeed前提のイベント連携、常時一定のスループットとSLAが不可欠な基幹系は、StarterではなくEssentialやDedicatedを選ぶべきです。逆に、変動トラフィックのWebアプリ、検証・PoC、小〜中規模のSaaSやAIアプリ試作では、無料枠から始められるStarterが最も費用対効果に優れます。

よくある質問

TiDB ServerlessとTiDB Cloud Starterは別物ですか？

同じサービスです。2025年8月12日に「TiDB Cloud Serverless」から「TiDB Cloud Starter」へ名称変更されました。接続文字列・エンドポイント・データは変わらず、アプリの改修は不要です。

無料枠だけでずっと使えますか？

無料枠の範囲内（インスタンスあたり行5GiB＋列5GiB＋月間50M RU、組織で最大5インスタンス）であれば継続的に無料で使えます。超過すると従量課金へ切り替わるため、月間上限とアラートの設定が実務上は重要です。

日本（東京リージョン）の料金は米国と同じですか？

いいえ。東京はプレミアムリージョンに分類され、標準リージョンより単価が割増になります。100万RU$0.10・行ストレージ$0.20/GiB・月は標準リージョンの基準値なので、東京で使う場合は公式料金表で最新単価を確認してください。

MySQLからそのまま移行できますか？

MySQL 8.0互換のため多くはそのまま動きますが、UDFや一部ストアドプロシージャなど非対応機能があります。DumplingとTiDB Lightningで移行し、Checksumで整合性を検証する流れが標準です。

ベクトル検索は追加設定が必要ですか？

Starterはベクトル検索を標準搭載しており、別エンジンの構築は不要です。埋め込みをテーブルに保存してSQLで類似検索でき、RAG構成にそのまま組み込めます。

関連記事

• OLTPとは｜OLAP・DWHとの違いとHTAP・AWS DB選定を比較解説
• Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説
• ベクトル検索とセマンティック検索の違い｜包含関係・仕組み・使い分けを実装目線で整理
• CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説：PostgreSQL互換側の分散SQL。方言で選び分ける際の対になる候補