## 24. 成長したときの移行パス

確認：2026年9月

最初は安く速い構成で始め、きっかけが来たら次へ移る。移行を楽にするために、**最初からやっておく備え**を守る。

| 始めの構成 | 移行先 | 移行のきっかけ | 最初からやっておく備え |
|---|---|---|---|
| Cloudflare Workers＋D1（エッジ構成） | Neon／RDS（Hyperdrive経由で接続） | 1データベースの容量上限に近づく、複雑なJOINやトランザクションが増えた | DrizzleなどでSQLite固有の書き方を避ける。データアクセスを1か所にまとめる |
| Supabase（DB・認証・ストレージ一体） | RDS＋Clerk等＋S3 | 費用の増加、細かいチューニングや閉域接続が必要 | 標準的なPostgres機能だけを使う。ユーザーIDは自前のテーブルでも保持する |
| Neon | RDS／Aurora | 常時高負荷になり、従量課金より固定費が安くなった | 接続文字列を環境変数で切り替えられるようにする |
| SQLite（Rails単一サーバー） | PostgreSQL | 複数台構成にしたい、書き込み待ちが目立つ | SQLite固有の書き方を避け、ActiveRecordの範囲で書く |
| Vercel（Next.js） | ECS／Cloud Run（コンテナ） | 費用の増加、AWSに集約したい | Next.jsのstandalone出力でコンテナ化できる状態を保つ。Vercel固有の機能への依存を最小にする |
| Render／Fly.io | AWS（ECS＋RDS＋Terraform） | 閉域網・監査・細かい権限管理が必要になった | Dockerfileでビルドし、設定はすべて環境変数から読む |
| Kamal（単一サーバー） | 複数台／ECS | 1台で処理しきれない、冗長化が必要 | アプリをステートレスにする。セッションとファイルはDB・S3に置く |
| Postgres全文検索（pg_bigm） | Meilisearch | §23-1 の目安を超えた | 検索処理を1か所（リポジトリ層）にまとめ、呼び出し側から検索エンジンを隠す |
| pgvector | Qdrant | §23-1 の目安を超えた | ベクトル検索を専用のインターフェース経由で呼ぶ |
| Postgresベースのジョブキュー | SQS／Valkey | §23-1 の目安を超えた | ジョブの投入と処理をインターフェースで抽象化する |
| Clerk | 他のIdP・自前認証 | 費用の増加、要件がClerkの範囲を超えた | OIDCの標準仕様で連携する。ユーザー情報の正本は自前のDBに持つ |
| モノリス | サービス分割 | §23-4 の目安に当たった | 機能ごとにディレクトリ・パッケージを分け、モジュール間の呼び出しを限定する |
| TypeScriptのバックエンド | 一部をGo／Rustに切り出し | CPU負荷・レイテンシがボトルネックになった | APIをOpenAPIで定義しておき、実装言語を差し替えられるようにする |
| Shopify | Medusa（独自コマース） | Shopifyで実現できない要件が増えた | 商品・顧客データを定期的にエクスポートできる状態にしておく |
| CloudWatchのみ | Grafana Cloud／Datadog | サービスが増え、横断的に調査したくなった | 最初からOpenTelemetryで計装する |
| 手作業のインフラ構築 | Terraform管理 | —（最初からTerraformにする） | 検証環境であってもコンソールでの手作業を避ける |