TiDBに関する雑多なアップデートを一週間分お届けするTiDB WEEKLY。 今週のアップデートをお届けします。
製品アップデート
TiDB Cloud リリースノート（7/14）
Dedicated のクロスリージョンリストアが使いやすく（7/14）
これまでは、リストア先のリージョンにCIDRブロックが割り当てられていない場合、事前にそのリージョンでクラスタを作っておく必要がありました。今回の変更で、Restoreページから直接CIDRブロックを作成できるようになっています。
公式ブログ等の更新
From One Week to 22 Minutes: How Bolt Migrated MySQL to TiDB（英語）
欧州・アフリカで2億人以上が利用するモビリティサービスのBoltが、MySQLからTiDBへ移行した事例です。既存のMySQLでは、テラバイト級のテーブルでスキーマ変更に1週間以上かかり、他の開発をブロックしていたこと、バックアップがシングルスレッドで長時間かかることが課題でした。 VitessはDDLの一貫性や手動リバランスの点で見送り、CockroachDBやYugabyteDBはアプリケーションの書き換えが必要になるため、MySQL互換のTiDBを選択しています。 結果として、スキーマ変更は1週間から22分に、60TBのバックアップは75分で完了するようになりました。
Novita Artifact Hosting + TiDB: Deploying AI-Generated Apps With One SDK Call（英語）
AIが生成したアプリケーションを本番で動かせない理由は、コードの品質ではなくデプロイ基盤にあります。
そうした問題意識から始まる記事です。
Novita Artifact HostingとTiDB Cloudの連携により、SDKの呼び出し1回でサンドボックスのコードを公開URLまで持っていけるようになりました。
database=True を指定するだけでTiDBインスタンスの作成、マイグレーションの実行、接続文字列の注入までが自動で行われます。
AIエージェントが生成するコードはNext.jsやDjangoなどMySQLに対応したものが多く、プロトコル互換であることの重要性が述べられています。
TiDB Cloud Cross-Region PiTR: Disaster Recovery Without a Second Production Stack（英語）
リージョン障害からの復旧を、本番の複製を常時動かさずに実現するクロスリージョンPiTRの解説です。 継続的バックアップ、S3経由のクロスリージョンレプリケーション、セカンダリリージョンでの復旧ポイント検証、オンデマンドのクラスタ復元という4つの機能を組み合わせています。 RPOは平均75秒以内、P99で90秒以内、P9999で120秒以内を目標とし、RTOは時間単位（クラスタサイズやバックアップ頻度で調整可能）としています。 スタンバイ環境の費用ではなく、バックアップストレージとレプリケーション、そして実際に障害が起きたときの復旧リソースにコストが集中する、というモデルです。 現時点ではAWSのみの対応となっています。
HTAP Was Right. AI Agents Are Proving Why.（英語）
DatabricksのLTAP（Lake Transactional and Analytical Processing）発表を受けた記事です。 AI文脈でのHTAP、つまりトランザクションと分析の統合の重要性を述べています。 AIエージェントは、オペレーショナルな状態の読み取り、履歴の参照、埋め込み検索、パターン分析、更新の実行を1つのワークフローの中で行います。 その定義からしてHTAPワークロードであり、データの一貫性が重要であると述べます。
The Multi-Tenant Agent Database: Why the Scale Problem Just Inverted（英語）
TiDB SCaiLE Europe 2026でのEd Huangの基調講演をまとめた記事です。 エージェントは「ランタイム（LLMのループ）」「スキル（ビジネスロジック）」「環境（コンピュート・ストレージ・データベース）」の3要素からなり、見落とされがちな「環境」こそが重要だ、という主張です。 そして、従来のデータベースが直面してきた「1つのデータセットが1台に収まらない」問題とは異なる課題が、エージェント基盤では生じていると指摘します。 それは「数百万の小さく隔離されたデータベース」という逆向きのスケール問題です。
それではまた来週。