db-platform-fit

db-platform-fit (M21) — バージョン · 料金／ロックイン · プラットフォームごとの機能サポート

M21 では、生のエンジンではなく、マネージドプラットフォームが課す制約に照らしてプロジェクトを監査します。 同じ Postgres スキーマでも、Neon（サーバーレス、スケール・トゥ・ゼロ、ブランチ機能）、RDS、Supabase（RLS 中心、PostgREST）では挙動が異なります。検出事項は両方の軸に反映されます。機能の不足（FK サポート、RLS）は設計上の問題であり、接続／コールドスタート／バージョンの問題はパフォーマンス上の問題です。

チェック項目

1. バージョンの最新性 — 宣言された／調査したエンジンのバージョンと、プラットフォームが現在サポートしている範囲を比較します。明らかに古いメジャーバージョンにはフラグを立てます。EOL 日や「サポート終了予定日」を決して捏造しないでください。 引用可能な情報源から正確な EOL が確認できない場合は、「古いメジャーバージョンです。サポート期間をプラットフォームに確認してください」と記載し、confidence: directional とします。WebFetch を使用する場合は、ベンダーが公開しているバージョン情報ページを引用してもかまいません。情報源を示せない数値を言い換えて記載せず、そのまま引用してください。
2. 料金／ロックインに関する誠実さ — ロックインのトレードオフを明示します（独自機能：Supabase Auth／RLS の結合、PlanetScale の Vitess シャーディング、D1 の SQLite 方言、DynamoDB のシングルテーブル設計、Aurora のストレージ形式）。料金、GB あたりのコスト、行数／リクエスト数の上限を決して捏造しないでください。 コストの種類（エグレス、ブランチ機能のコンピューティング、読み取り／書き込みユニットなど）を示し、正確な金額はベンダーの最新の料金ページで確認する必要があることを伝えます。規模は幅を持たせて示してください。
3. プラットフォームごとの機能サポート — 最優先のチェック項目は FK サポートです。
   • PlanetScale / Vitess — 歴史的に外部キーを適用しません（シャーディングされた FK には制限があります）。DB が適用する FK に依存するスキーマには、アプリケーションレベルの整合性チェック、または FOREIGN_KEY_CHECKS への対応が必要です。→ 設計＋パフォーマンス。FK が宣言されているのに適用できない場合は sev 4。
   • Cloudflare D1 / SQLite — FK は存在しますが、PRAGMA foreign_keys を ON にする必要があります。並行処理と DB サイズには上限があります。
   • DynamoDB / Firestore — FK／JOIN はありません。整合性の確保はアプリケーション側の責任です（M3 で再配置）。
   • サーバーレスドライバー（Neon／PlanetScale HTTP、D1） — サーバーレス／エッジ環境から直接、長時間存続する PG 接続を行うのはアンチパターンです。db-connection-pooling（M15）と相互確認します。
   • Supabase — 自動 REST／Realtime API に公開されているテーブルでは、RLS を ON にする必要があります。db-security-access（M10）と相互確認します。公開テーブルで RLS が OFF の場合は sev 5（設計上の問題）です。
   • CockroachDB / Yugabyte — PG ワイヤープロトコル互換ですが、分散型です。serial／sequence のホットスポット、特定の PG 拡張機能が使えないこと、分離レベルのデフォルト設定の違いに注意してください。

Tier-0 静的チェック

references/detection-signals.md のシグナル（supabase/ ディレクトリ、@planetscale/database、@neondatabase/serverless、wrangler.toml [[d1_databases]]、@libsql/client、接続文字列／依存関係に含まれる cockroach／yugabyte）からプラットフォームを検出します。設定／マイグレーションから宣言されたエンジンのバージョンを解析します。宣言された FK 制約と、プラットフォームの FK サポート状況を照合します。サーバーレス／エッジのエントリーポイントで直接 PG ドライバー（pg、Pool）が使用されていないか検出します。

Tier-1 検証クエリ

• Postgres 系：SELECT version(); と SHOW server_version;。
• MySQL／PlanetScale：SELECT VERSION(); と SELECT @@foreign_key_checks;。宣言された FK が実際に存在するか確認します：SELECT * FROM information_schema.table_constraints WHERE constraint_type='FOREIGN KEY';
• Supabase RLS：SELECT relname, relrowsecurity FROM pg_class WHERE relkind='r'; と pg_policies。
• D1／SQLite：PRAGMA foreign_keys;。エンジン／プラットフォームに接続できない場合は needs_api とし、誤って pass にしないでください。

検出事項

schema/finding.schema.json に従って出力します。ID の例：

• M21.platform.fk_unenforced_on_vitess — FK 制約が宣言されていますが、PlanetScale/Vitess では強制されません （fail、重大度 4、軸 both、信頼度は Tier-1 なしでは directional、Tier-1 ありでは established）。
• M21.platform.rls_off_supabase — RLS が無効な状態で、テーブルが Supabase API 経由で公開されています（fail、重大度 5、 軸 design、Tier-1 ありでは信頼度 established）。
• M21.platform.engine_version_old — 明らかに古いメジャーエンジンバージョン（warn、重大度 3、軸 both、 信頼度 directional。EOL 日付を捏造せず、ベンダーのページを引用するか、判断を保留します）。
• M21.platform.serverless_direct_pg — エッジ／サーバーレスからの、長時間接続を維持する直接 PG 接続（warn、 重大度 4、軸 performance。M15 を相互参照します）。 各検出事項では、evidence.observed に実際の設定／DDL／バージョン文字列をそのまま引用します（シークレットはマスキングします）。 verification.reproduce は、上記の $DATABASE_URL を使用する実行可能なコマンドです。verification.method は connection_introspect、schema_introspect、または manual_review です。expected_impact には {axis, confidence, magnitude, rationale} を記載します。影響度は範囲で示し、単独の％は使用しません。

誠実性

• 検出事項でも設計に関する推奨事項でも、EOL 日付、価格、クォータを決して捏造しません。 WebFetch でベンダーの 最新ページを引用するか、信頼度を directional として「ベンダーのページで確認してください」と記載し、判断を保留します。
• ロックインはトレードオフであり、自動的に欠陥となるものではありません。何を手放すことになるかを明示し、道徳的な評価はしません。
• 出典に基づく EOL 情報がない場合、バージョンが「古い」ことの信頼度は directional であり、上限を設定することはありません。FK が強制されない場合の上限は重大度 4 です（孤立した金銭関連／認証関連の行を直接可能にする場合を除き、重大度 5 にはしません）。アクセスできないプラットフォームは needs_api とします。