db-platform-fit

db-platform-fit（M21）— 版本 · 定价/锁定 · 各平台功能支持

M21 根据托管平台施加的限制审查项目，而非仅审查底层引擎。 同一套 Postgres 架构在 Neon（无服务器、缩至零、分支）与 RDS、Supabase（以 RLS 为核心、PostgREST）上的表现各不相同。审查结果会影响两个方面：功能缺口（外键支持、RLS）属于设计问题；连接、冷启动和版本问题属于性能问题。

检查内容

1. 版本时效性 — 声明或检测到的引擎版本与平台当前支持范围的对比。明确标记过旧的主版本。绝不编造 EOL 日期或“支持至”日期。 如果找不到可引用来源来确认确切的 EOL 信息，应注明“较旧的主版本，请向平台确认支持期限”，并标记 confidence: directional。使用 WebFetch 时，可以引用供应商发布的版本页面；应直接引用，不要转述无法从来源核实的数字。
2. 如实说明定价/锁定 — 指明锁定方面的权衡（专有功能：Supabase Auth/RLS 耦合、PlanetScale Vitess 分片、D1 的 SQLite 方言、DynamoDB 单表设计、Aurora 存储格式）。绝不编造价格、每 GB 成本或行数/请求配额。 说明成本类别（如出口流量、分支计算、读/写单位），并指出具体数值必须以供应商当前定价页面为准。仅标明大致级别。
3. 各平台的功能支持 — 外键支持是重点检查项：
   • PlanetScale / Vitess — 历来不强制执行外键（且分片外键受到限制）；依赖数据库强制执行外键的架构需要在应用层保障完整性，或了解 FOREIGN_KEY_CHECKS。→ 设计 + 性能；声明了外键但无法强制执行时，严重级别为 4。
   • Cloudflare D1 / SQLite — 支持外键，但必须启用 PRAGMA foreign_keys；并发能力有限，且数据库大小有上限。
   • DynamoDB / Firestore — 完全不支持外键/联接；完整性由应用负责（M3 负责迁移）。
   • 无服务器驱动（Neon/PlanetScale HTTP、D1） — 从无服务器/边缘环境直接使用长期运行的 PG 连接属于反模式 → 交叉检查 db-connection-pooling（M15）。
   • Supabase — 任何通过自动 REST/Realtime API 暴露的表都必须启用 RLS → 交叉检查 db-security-access（M10）；暴露的表未启用 RLS 时，严重级别为 5（设计）。
   • CockroachDB / Yugabyte — 与 PG wire 兼容，但属于分布式数据库：串行/序列可能成为热点、不支持某些 PG 扩展、默认隔离级别不同。

Tier-0 静态检查

根据 references/detection-signals.md 中的信号检测平台（supabase/ 目录、 @planetscale/database、@neondatabase/serverless、wrangler.toml [[d1_databases]]、 @libsql/client、连接字符串/依赖项中的 cockroach/yugabyte）。从配置/迁移文件中解析声明的引擎版本。将声明的外键约束与平台的外键支持情况交叉核对。 检测无服务器/边缘入口点中使用的直接 PG 驱动（pg、Pool）。

Tier-1 验证查询

• Postgres 系列：SELECT version(); 和 SHOW server_version;。
• MySQL/PlanetScale：SELECT VERSION(); 和 SELECT @@foreign_key_checks;；检查声明的外键是否确实存在：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，置信度：静态分析为 directional / 使用 Tier-1 时为 established）。
• M21.platform.rls_off_supabase — 通过 Supabase API 暴露的表已禁用 RLS（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 （除非会直接导致财务/身份验证记录孤立，此时除外）。无法访问的平台 → needs_api。