TiDBに関する雑多なアップデートを一週間分お届けするTiDB WEEKLY。 今週のアップデートをお届けします。
製品アップデート
TiDB Cloud リリースノート（8/4、8/5）
Premium のバックアップに Custom Retention Mode が追加（8/5）
TiDB Cloud Premium の自動バックアップで、保持のしかたを2つのモードから選べるようになりました。Custom Retention Mode では保持期間を3日から33日の範囲で指定でき、日次スナップショットを作成する時刻も選択できます。従来どおりの設定は、Standard Bundle Mode を選びます。
汎用 Webhook 経由のアラート通知に対応（8/4）
TiDB Cloud Essential / Premium / Dedicated で、汎用のWebhook宛にアラートを通知できるようになりました。利用できるのは、組織のサポートプランが Enterprise または Premium の場合です。 従来からあるemail, Slack, PagerDutyに対応していないサービスへの通知も可能となりました。
Premium の changefeed が Amazon MSK Provisioned に対応（8/4）
AWS上の TiDB Cloud Premium から、AWS PrivateLink 経由で Amazon MSK Provisioned クラスタへ行変更イベントをストリーミングできるようになりました。 パブリックな経路を通さずにchangefeedのシンクを構成できます。
公式ブログ等の更新
Why Attend TiDB SCaiLE 2026: Same Complexity, Different Clock Speeds（英語、8/6）
10月15日にカリフォルニア州マウンテンビューのComputer History Museumで開催される、単日カンファレンス TiDB SCaiLE 2026 の告知記事です。 セッションは「AI-Native: Infinite Agents」と「Enterprise: Infinite Data」の2トラック構成で、前者はエージェント駆動のプロビジョニングやテナントごとの分離、ベクトル検索とコスト管理を、後者は基盤統合・移行・マルチリージョンでの可用性・本番運用を扱います。
Open Source Data Layers Will Win the AI Future（英語、8/5）
コーディングエージェントによってアプリケーションコードの書き直しが安価になった一方で、データベースの移行は依然として高くつく、という非対称性から出発する記事です。 モデルもフレームワークもエージェントのアーキテクチャも短期間で置き換わるが、顧客のコンテキスト、権限、トランザクション、ワークフローの状態はデータベースに残り続ける。 だからこそデータレイヤーこそがアプリケーションの実質的なコントロールプレーンであり、そこをオープンソースにしておくことが将来の選択肢を確保することになる、という論旨です。
Migrating Real-Time Data into TiDB with Debezium CDC（英語、8/4）
Debezium と Apache Kafka を使って、各種データベースの変更を TiDB へリアルタイムに流し込むチュートリアルです。 Docker Compose での Kafka / Kafka Connect の起動、ソース側の変更キャプチャの有効化、コネクタ設定、REST API での登録まで5ステップで手順が示されており、初期スナップショットと継続同期の両方を試すことができます。
Vector Search Meets Distributed SQL: Why Agentic AI Does Not Need Another Database（英語、7/30）
エージェント型AIのために既存スタックへベクトルデータベースを足す必要はない、という記事です。 システムを1つ増やすたびに同じデータのコピーやスライスが増え、それぞれに取り込み経路が必要になり、同期・運用・「どのデータがどこにあるのか」という開発者側の混乱という3つのコストが積み上がるという整理です。
つい先日AWS DynamoDBがベクトル検索に対応しましたが、既存のDBがベクトル検索をサポートしてきているため、単独のベクトルDBの必要性が性能や固有の演算子のみになってきているのを感じます。どのように差別化していくのか、気になるところです。
TiDB Log Compaction: Faster Point-in-Time Recovery for Large Clusters（英語、7/27）
PITR（Point-in-Time Recovery）を高速化するためのログ圧縮機能の解説記事です。 バックアップしたログファイルをオフラインで事前にソート済みSSTへ変換しておき、リストア時にはSSTを取り込んで未圧縮のレンジだけログをリプレイする、という仕組みです。 従来のPITRはリストア時に断片化したログを読み、細かい書き込みを大量に再構築し、その後のRocksDBの書き込み増幅まで引き受ける必要があり、大規模クラスタでは現実的な時間に収まりませんでした。 社内ベンチマークでは、4.2TiBの読み取り中心のワークロードでリストア全体が94.3%短縮（ログリストアのフェーズは98.9%短縮）、206.6TiBの書き込み中心の大規模クラスタでは従来は非現実的だったリストアが1時間48分で完了したと報告されています。
それではまた来週。