Cloudflare Workers＋D1（エッジ構成） → Neon／RDS（Hyperdrive経由で接続）
移行のきっかけ1データベースの容量上限に近づく、複雑なJOINやトランザクションが増えた
最初からやっておく備えDrizzleなどでSQLite固有の書き方を避ける。データアクセスを1か所にまとめる
§24
成長したときの移行パス
最終確認：2026年9月
最初は安く速い構成で始め、きっかけが来たら次へ移る。移行を楽にするために、最初からやっておく備えを守る。
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にする）
最初からやっておく備え検証環境であってもコンソールでの手作業を避ける