判断の目安となる数値

PostgreSQL単体

まず単体で足りる範囲（目安）データ量が数百GB〜1TB程度、書き込みが秒間数千件程度まで

次の手を打つきっかけ読み取りのCPU使用率が継続して高い（70%超が続く）

次の手リードレプリカ → キャッシュ → テーブル分割（パーティション）

コネクション数

まず単体で足りる範囲（目安）アプリのインスタンス数×プール数が数百程度まで

次の手を打つきっかけ接続数の上限に近づく、サーバーレスから接続する

次の手RDS Proxy／PgBouncer

日本語全文検索（pg_bigm）

まず単体で足りる範囲（目安）数百万件程度、応答が100ms前後に収まる範囲

次の手を打つきっかけ表記揺れ吸収・ファセット・サジェストが必要、応答が遅くなる

次の手Meilisearch

ベクトル検索（pgvector＋HNSW）

まず単体で足りる範囲（目安）数百万ベクトル程度

次の手を打つきっかけ数千万件以上、または反復インデックススキャン（hnsw.iterative_scan）を使っても条件付き検索の応答が目標に届かない

次の手Qdrant

Postgresベースのジョブキュー

まず単体で足りる範囲（目安）Go（River）は秒間数千件、Rails（Solid Queue）・TypeScript（pg-boss）は秒間数百件程度

次の手を打つきっかけ左の目安を超える、またはDB負荷の大半をキューが占める

次の手SQS、Valkey（BullMQ／Sidekiq）

SQLite（単一サーバー）

まず単体で足りる範囲（目安）書き込みの同時実行が少なく、サーバー1台で足りる範囲

次の手を打つきっかけ複数台構成にしたい、書き込み待ちが目立つ

次の手PostgreSQL

Lambda と 常駐コンテナ

目安リクエストが一日中途切れず続くなら、常駐コンテナの方が安くなりやすい

判断まばらなリクエスト・イベント処理はLambda、常時トラフィックはECS／Cloud Run

Lambdaの実行時間

目安1回あたり最大15分

判断超える可能性がある処理はECSタスクかStep Functionsで分割

コールドスタート

目安TypeScript・Pythonは短め、Goは非常に短い、JVMは長い（SnapStartで緩和できる）

判断起動時間が体感に効く同期APIでは、JVMのLambdaを避ける。手順1でKotlinが決まっている場合はSnapStartを検討する

PaaS（Vercel等）からの移行

目安月額費用が、自前コンテナ運用にかかる人件費を上回り始めたら

判断§24 の移行パスに従う

Kubernetes

目安常時稼働するサービスが10前後以上あり、専任の運用担当がいる

判断それ未満ならECS／Cloud Run／Kamal

マルチリージョン

目安目標復旧時間が分単位で、リージョン全体の障害を許容できない

判断それ以外はマルチAZで十分

WebSocket同時接続（Node.js）

目安1プロセスあたり数千〜1万程度

判断超えるならプロセスを増やしてPub/Subで連携、またはGo／Elixir

WebSocket同時接続（Go）

目安1台あたり数万〜10万程度

WebSocket同時接続（Elixir／Phoenix）

目安1台あたり数十万以上

判断プレゼンスや配信が中核ならElixir

p99レイテンシ 100ms程度

目安どの言語でも達成できる

判断言語選定の理由にならない。DBとキャッシュを見直す

p99レイテンシ 10ms未満が厳格に必要

目安GCのある言語では上振れの管理が難しくなる

判断Rustを検討（§2-10）

開発者1〜2人

目安言語を1つに絞る

判断フロントと同じTypeScript、またはRails単体

開発者10人以上

目安モジュール構造を強制する仕組みが必要

判断NestJS、Kotlin（Spring）、Goならパッケージ境界のルール化

モノリスの分割

目安チーム間でデプロイ待ちが常態化した、または特定機能だけ独立してスケールさせる必要が明確になった

判断それまではモノリスのまま、モジュール境界だけ明確にしておく

言語を1つ追加する

目安既定の言語では要件を満たせない、または明らかに大きな差がつく

判断§2-10 の混在ルールに従う