TiDB 2026年6月2日のリリースノート解説: Starter上限、Top RU、暗号化とTTL監視

TiDB Cloud は 2026年6月2日、Starter、Essential、Premium にまたがる運用寄りの更新を公開しました。大規模に Starter を増やす組織、RU消費を見たい Essential 利用者、暗号化やTTL監視を重視する Premium 利用者で確認点が分かれます。

要点

• TiDB Cloud Starter では、インスタンスとブランチの合計上限に関する Instance Capacity Plan が案内されました。
• 有料組織では、標準で Starter インスタンスとブランチを合計100件まで作成でき、ブランチも1件として数えられます。
• TiDB Cloud Essential では、N. Virginia と Tokyo で Top RU が公開プレビューとして使えるようになりました。
• TiDB Cloud Premium では、Alibaba Cloud KMS を使うデュアルレイヤーデータ暗号化と、TTLジョブを見やすくする2つの監視指標が追加されました。

今回の更新で変わること

今回のリリースノートは、一つの大型機能というより、TiDB Cloud のプランごとに「規模」「費用可視化」「セキュリティ」「データ保持」を整える更新として読むと理解しやすいです。Starter では Instance Capacity Plan が導入され、有料組織で作成できる Starter インスタンスとブランチの標準上限が合計100件と説明されています。ここで重要なのは、ブランチも個別に数えられる点です。開発、検証、AIエージェントの実験、顧客別環境などでブランチを多用するチームは、実インスタンス数だけを見ていると上限の見積もりを誤ります。さらに TiDB Cloud API でもこの上限が適用され、上限到達時には新しい Starter インスタンスやブランチの作成リクエストが拒否されるため、自動作成の仕組みを持つチームは失敗時の扱いまで設計しておきたいです。

Essential では Top RU が N. Virginia と Tokyo で公開プレビューとして提供されます。Top RU は、分単位でRU消費が大きいSQL文を表示し、コスト削減や負荷調査の手がかりになります。TiDB Cloud Essential を小さく始めたチームでも、AIアプリや分析用途でクエリが増えると、どのSQLが費用や性能に効いているかを早めに見たい場面が出ます。段階的なロールアウトで、早期利用にはサポート連絡が必要とされています。

Premium では、Alibaba Cloud 上のデュアルレイヤーデータ暗号化とTTL監視指標が追加されました。前者は Alibaba Cloud KMS の自社鍵で保存データを暗号化する選択肢で、コンプライアンスや鍵管理の責任分界に関係します。後者は TTL Schedule Delay のテーブル数と、TTL による挿入・削除行数を日単位で見る指標です。TTLはデータ保持ポリシーの実装に関わるため、ジョブ遅延や削除量を監視できることは、単なるメトリクス追加以上に運用上の意味があります。

対象になりそうなユーザー・チーム

Starter を多く作る開発組織、TiDB Cloud API で環境を自動生成するチーム、Essential のRU消費を追いたい運用担当、Alibaba Cloud 上のPremiumで鍵管理や保存データ保護を重視するセキュリティ担当に関係します。

実務で確認したいポイント

• Starter のインスタンス数だけでなく、ブランチ数も含めて上限に近づいていないか確認する。
• APIで環境を作成する処理が、上限到達時の拒否を利用者に分かる形で扱えるか確認する。
• Essential の Top RU 対象リージョンと、自社環境での利用可否を確認する。
• Premium の暗号化要件、Alibaba Cloud KMS の鍵運用、TTLジョブ監視のアラート設計を見直す。

結局、今回の更新をどう読むべきか

6月2日の更新は、TiDB Cloud を実験的に使う段階から、数を増やして運用する段階へ移るための足場を整える内容です。Starter の上限、Essential のRU可視化、Premium の暗号化とTTL監視を、自社の利用規模と統制要件に照らして確認しておきたいです。