PostgreSQLからTiDBへ、稼働中SaaSで進める段階的DB移行の実践と再設計への展望

クラウドサービスを稼働させたまま、その中核となるデータベースをPostgreSQLから分散型DB「TiDB」へ移行するには、どのような判断と実践が必要なのか。

2026年7月22日に開催された「AI DevEx Conference 2026」では、株式会社コラボスタイルの波多野 謙介氏、鬼頭 昌孝氏、後藤 佳汰氏が、性能劣化や垂直スケールの限界を背景とした移行判断、Strangler Fig Patternによる段階的移行、AI-DLCを活用した横断体制、異機種DB移行で直面した課題を紹介した。

本稿では、その取り組みと、TiDBに最適化した再設計を見据える今後の展望をレポートする。

【登壇者】
株式会社コラボスタイル CIO 波多野 謙介氏

株式会社コラボスタイル 開発部 グループマネージャー 鬼頭 昌孝氏

株式会社コラボスタイル 開発部 インフラエンジニア 後藤 佳汰氏

異なる立場から読み解く、
稼働中サービスのデータベース移行

「AI DevEx Conference 2026」で行われたセッション「PostgreSQLからTiDBへ。分散型DB移行の意思決定と実践」には、株式会社コラボスタイルのCIOを務める波多野 謙介氏、開発部 グループマネージャーの鬼頭 昌孝氏、開発部 インフラエンジニアの後藤 佳汰氏が登壇した。セッションは、経営、開発マネジメント、インフラという異なる立場から、データベース移行プロジェクトを振り返るパネルディスカッション形式で進められた。

波多野氏は、このパネルディスカッション形式を採用した理由について、データベース移行が単なるインフラの入れ替えではないためだと説明した。10年以上運用してきたクラウドサービスを稼働させたまま、その中核となるデータベースを移行するには、経営上の意思決定、チームを横断した協力、現場レベルの技術判断が必要になる。異なる役割を担う3氏がそれぞれの視点から話すことで、プロジェクトの全体像を伝える狙いがあった。

同社が提供する主なサービスは、2,000社以上に導入されているワークフローシステム「コラボフロー」と、社外からの申請文書を受け付ける「コラボフォーム」である。移行前はいずれもAWS Aurora PostgreSQL Serverlessを利用し、各データベースにリードレプリカを配置していた。

ただし、両サービスのデータベース構成は異なる。コラボフローは、テナントごとの専用DBとセッション管理専用DBを持つ「テナント分離型」である。一方、コラボフォームは、サービス間の共通情報を管理する共通DBと、サービス固有の情報を管理するサービスDBからなる「機能分離型」である。

波多野氏は、多数のテナントDBを抱えるコラボフローを「ラスボス」、比較的新しい構成を採るコラボフォームを「中ボス」と表現した。同社は、最初から大規模なテナントDB群へ着手するのではなく、影響を限定できる領域から段階的にTiDB化する方針を選んだのである。

垂直スケールの限界を越えるため、
TiDBへの移行を決断

TiDBへの移行を検討した背景には、サービスの成長に伴って顕在化した三つの課題があった。検索・集計パフォーマンスの劣化、書き込み負荷に対する垂直スケールの限界、レプリケーション遅延による障害リスクである。サーバーの性能を引き上げる垂直スケールだけでは、増え続けるデータ量と処理負荷に対応し続けることが難しくなっていた。

同社がTiDBに期待したのは、水平スケーラビリティによる容量拡張、高可用性と安定運用の両立、インフラコストの削減である。加えて、大きな決め手となったのが、アプリケーション側に実装していたRead／Writeの振り分け処理を簡素化できる点だった。

従来構成では、読み込みをリードレプリカへ送り、書き込みをプライマリ側で処理するため、アプリケーション側でRead／Writeを明示していた。機能追加や改修のたびに関連コードを変更する必要があり、長年運用してきたサービスでは修正対象も膨大になる。TiDB側で負荷を分散できれば、こうした振り分けコードの大幅な修正を避けられると判断した。

ただし、PostgreSQLからTiDBへの移行には明確な負担もある。TiDBはMySQL互換のデータベースであり、PostgreSQLとはSQL構文、データ型、スキーマ、接続ドライバーなどが異なる。既存アプリケーションを修正せず、そのまま移せるわけではない。

それでも同社は、検索・集計処理の改善、コスト最適化、自動シャーディング、将来の分析機能など、移行後に得られる利点が負担を上回ると判断した。TiDBの導入実績や事例も、意思決定を後押ししたという。

波多野氏は、「51対49だとしても、どちらかを選んで前に進むことが大事です」と語った。すべての不確実性がなくなるまで待つのではなく、メリットとデメリットを比較し、将来のサービス成長に必要な基盤を選ぶ。TiDBへの移行は、技術選定であると同時に経営判断でもあった。

Strangler Fig PatternとAI-DLCで
機能開発と移行を並行

稼働中のSaaSでは、データベース移行のために機能開発を止めることはできない。そこで同社が採用したのが、影響の小さい領域から新しい仕組みに置き換え、対象を徐々に広げる「Strangler Fig Pattern」である。

最初にTiDB化したのは、コラボフローのセッションDBと、コラボフォームの共通DBである。コラボフローのテナントDBとコラボフォームのサービスDBはPostgreSQLに残し、影響を限定しながら移行手順や運用方法を確認した。

鬼頭氏は、この進め方について次のように説明した。「影響の少ない領域、ここからなら進められるという小さなデータベースから始めました。そこでスモールサクセスを少しずつ積み上げていく戦略です」

両サービスの「外堀」から着手し、そこで得た手順や知見を次の対象へ適用することで、移行リスクを抑えながら全面移行を目指す。

先行移行では、リードレプリカやRDS Proxyを含む従来構成をTiDBへ置き換え、構成の簡素化とインフラコストの削減を実現した。高負荷時間帯にも安定して稼働しているという。

実行時間は最速時で80％短縮され、処理速度は5倍となった。平均値では86.7％短縮して7.5倍、最遅時では90％短縮して10倍という結果が得られた。また性能改善を数値で確認できたことは、次の移行へ進むモチベーションにもなった。

組織面では、インフラ、アプリケーション、各サービスのドメイン知識を持つ人材を集める横断的なプロジェクト制を採用した。固定化されたチームだけでは、組織構造がシステム構造へ反映される「コンウェイの法則」によって、横断的な変更が進みにくいためである。

さらに、AWSが提唱するAI-DLC(AI駆動開発ライフサイクル)を採用し^*、AIを開発の初期段階から認知負荷やコンテキストスイッチを抑えながら、移行への集中と開発スピードの両立を図った。「固定されたチームだけで進めるのではなく、必要な人を集めてプロジェクトを編成し、AIを初手から活用しています。柔軟に組織を編成しながら、スピードを保って進める形です」

鬼頭氏によると、異なる知識を持つメンバーがAIの出力を共同でレビューすることで、ドメイン知識の共有も進んだという。後藤氏も、サービスや技術領域に詳しいメンバーと確認を進めることで、作業の速度と効率が高まったと振り返った。段階的な移行と横断的な体制が、機能開発とDB移行を並行する支えとなった。

*：コラボスタイルにおけるAI-DLCの参考記事
●AI-DLC 導入を加速させたのは「人」の「つながり」だった
https://aws.amazon.com/jp/builders-flash/202601/accelerate-ai-dlc/
●AI-DLCを“そのまま導入しなかった”話 〜組織に合わせてアジャストした 私たちの実践共有〜 https://speakerdeck.com/hiroramos4/aidlc-casestudy

異機種DB移行の壁を越え、
TiDB向けの再設計へ

PostgreSQLからTiDBへの移行では、データ型、スキーマ、制約、アクセス制御など、異機種DBならではの課題に直面した。 

データ型とスキーマでは、TypeORMとの型マッピングの違いに対応し、PostgreSQL固有のスキーマを取り除く必要があった。外部キーについても、分散DBにおける性能への影響を考慮し、従来の設計を見直した。 

鬼頭氏は、従来のRDBと分散DBでは設計上の考え方を変える必要があると説明した。「分散型データベースでは、外部キーが性能に影響する場合があります。そこで、アプリケーション側で制約を担保し、実際の外部キーは設定しない方法を検討しました」 

PostgreSQLのRow Level Security、いわゆるRLSに依存していたアクセス制御も見直した。「アクセス制御についても、データベース固有の機能に依存せず、アプリケーション側で行う設計へ見直しています」 

DB固有の機能への依存を減らし、移植性を高める狙いである。外部キーとアクセス制御の見直しは、データベースとアプリケーションの責任範囲を組み直す作業でもあった。 

また、コラボフローには実行時にテーブルを動的に作成する仕組みがあり、テナントごとにテーブル数や構成が異なる。固定スキーマを一括変換するだけでは対応できず、各DBの状態に応じた処理が必要になった。 

AIによる変換も常に期待どおりになるとは限らないため、結果を人間が確認する二重検証を実施した。トランザクションでは、悲観的トランザクションとREAD COMMITTEDを採用し、リトライ対応も実装している。 

スキーマとデータの移行では、まず「SQLines」でスキーマを自動変換し、変換漏れや型の違いを手作業で修正した。資料では、PostgreSQLの「timestamptz」をTiDB側の「TIMESTAMP(3)」へ変更した例が示されている。その後、「Navicat」でデータをマッピングして転送し、移行結果を検証した。 

自動変換だけでは正確に移行できず、手動補正と目視確認が不可欠だった。効率より確実性を優先したことが、先行移行の成功につながったのである。 

ただし、この方法を多数のテナントDBへ適用するには時間がかかる。Navicatでは、1テナントのデータ転送に4～5時間程度かかる場合があった。現在は、多数のDBの一括転送と自動追加、TiDBへの転送、リアルタイムの進捗管理、高速転送に対応する別のツールを検証している。 

 検証中のツールでは、1テナントを約2時間で転送できる見込みだが、所要時間はまだ確定していない。約2,000のテナントDBを一括で切り替えることはできないため、対象を分けた段階的なロールアウトが必要になる。 

 ロードマップは二段階である。現在のStage 1では、既存のDB構成を変えず、TiDBへ確実に移すリフト＆シフトを検証している。無停止または停止時間を最小限にした移行方法の検証も進めている。 

続くStage 2では、サービスの保守性と拡張性を維持しながら、TiDBの分散DBとしての特性を引き出せるテーブル構成へ再設計する。「まずは既存の構成を維持したまま、確実に移します。その後、分散DBの強みを生かせる形に再設計し、改めてマイグレーションしていくことが最終的な目標です」 

鬼頭氏は、Stage 1の検証と並行して、Stage 2に向けた再設計も進めていると説明した。既存構成を載せ替えるだけでなく、TiDBに適したデータモデルへ作り直すことが、サービスの保守性や拡張性、さらなる成長につながるとの考えである。 

 「ラスボス」の先に、サービスの成長を描く

セッションの最後に、3氏は今後の移行に向けた意気込みを語った。 

後藤氏は、PostgreSQLからTiDBへの移行について、当初の想定以上に大変な作業だったと振り返った。一方で、普段は経験できないプロジェクトに関われることが自身の成長につながり、楽しさも感じているという。「チームのみんなで楽しみながら、ラスボスを倒したいです」 

鬼頭氏は、技術的な難易度だけでなく、メンバーが前向きに取り組める環境づくりを重視した。「AIを使いながら、みんなが楽しんで移行できる環境を整えていきたいです」 

波多野氏は、約2,000のテナントDB群を段階的に移すプランニングについて、難易度が高いからこそ面白い取り組みだと評価した。今回のプロジェクトで得た移行手順やツール選定、段階的なロールアウトの知見を、別の機会に外部へ共有したいと述べた。 

コラボスタイルの取り組みは、PostgreSQLをTiDBへ一括で置き換えるプロジェクトではない。影響の小さいDBから実績をつくり、異機種DBの差異を一つずつ解消しながら、多数のテナントDBへ対象を広げる。その先には、TiDBに最適化したDB設計へ移行し、分析機能やベクトル検索などを新たなサービス価値につなげる構想がある。 

現在の性能・運用課題を解消するための基盤移行と、将来の価値を生み出すための再設計を二段階に分けたことが、このプロジェクトの軸である。技術、組織、AI活用の三方向から難易度の高い移行を進めるコラボスタイルの試みは、稼働中サービスのデータベース刷新を検討する企業にとって、実践的な示唆を与えるものとなった。