db-platform-fit

---
name: db-platform-fit
description: Managed-platform fitness (M21) — checks the project against the realities of its hosting platform (Supabase, Neon, PlanetScale, Turso, Cloudflare D1, CockroachDB, Yugabyte, DynamoDB, RDS/Aurora). Engine version currency (without fabricating EOL dates), honest pricing / vendor lock-in trade-offs, and per-platform feature support — most importantly foreign-key support (PlanetScale Vitess historically restricts FKs; D1/SQLite, serverless drivers, connection limits). Feeds the Design & Integrity AND Performance & Scale scores.
license: MIT
---

# db-platform-fit (M21) — version · pricing/lock-in · per-platform feature support

M21 audits the project against constraints imposed by the **managed platform**, not the raw engine.
The same Postgres schema behaves differently on Neon (serverless, scale-to-zero, branching) vs RDS vs
Supabase (RLS-centric, PostgREST). Findings feed both axes: feature gaps (FK support, RLS) are design;
connection/cold-start/version issues are performance.

## What it checks
1. **Version currency** — the declared/introspected engine version vs the platform's current supported
   range. Flag clearly-old majors. **Never fabricate an EOL date or a "supported until" date.** If the
   exact EOL is not known from a citable source, say "older major, confirm support window with the
   platform" and mark `confidence: directional`. With `WebFetch` you MAY cite the vendor's published
   version page; quote it, don't paraphrase a number you can't source.
2. **Pricing / lock-in honesty** — name the lock-in trade-off (proprietary features: Supabase Auth/RLS
   coupling, PlanetScale Vitess sharding, D1's SQLite dialect, DynamoDB single-table design, Aurora
   storage format). **Never invent a price, a per-GB cost, or a row/request quota.** State the
   *category* of cost (egress, branching compute, read/write units) and that exact figures must be
   confirmed on the vendor's current pricing page. Magnitude banded only.
3. **Per-platform feature support — FK support is the headline check:**
   - **PlanetScale / Vitess** — historically does not enforce foreign keys (and sharded FKs are
     restricted); a schema relying on DB-enforced FKs needs app-level integrity or `FOREIGN_KEY_CHECKS`
     awareness. → design + performance, sev 4 when FKs are declared but unenforceable.
   - **Cloudflare D1 / SQLite** — FKs exist but `PRAGMA foreign_keys` must be ON; limited concurrency,
     DB size ceilings.
   - **DynamoDB / Firestore** — no FKs/joins at all; integrity is an application concern (M3 re-homes).
   - **Serverless drivers (Neon/PlanetScale HTTP, D1)** — direct long-lived PG connections from
     serverless/edge are an anti-pattern → cross-checks `db-connection-pooling` (M15).
   - **Supabase** — RLS must be ON for any table exposed via the auto REST/Realtime API → cross-checks
     `db-security-access` (M10); RLS-off on an exposed table is sev 5 (design).
   - **CockroachDB / Yugabyte** — PG wire-compatible but distributed: serial/sequence hotspots, no
     certain PG extensions, different isolation defaults.

## Tier-0 static checks
Detect the platform from `references/detection-signals.md` signals (`supabase/` dir,
`@planetscale/database`, `@neondatabase/serverless`, `wrangler.toml [[d1_databases]]`,
`@libsql/client`, `cockroach`/`yugabyte` in connection string/deps). Parse declared engine version from
config/migrations. Cross-reference declared FK constraints against the platform's FK-support reality.
Detect direct-PG drivers (`pg`, `Pool`) used in a serverless/edge entrypoint.

## Tier-1 verification query
- Postgres family: `SELECT version();` and `SHOW server_version;`.
- MySQL/PlanetScale: `SELECT VERSION();` and `SELECT @@foreign_key_checks;`; inspect whether declared
  FKs actually exist: `SELECT * FROM information_schema.table_constraints WHERE constraint_type='FOREIGN KEY';`
- Supabase RLS: `SELECT relname, relrowsecurity FROM pg_class WHERE relkind='r';` and `pg_policies`.
- D1/SQLite: `PRAGMA foreign_keys;`. When the engine/platform isn't reachable → `needs_api`, never a
  false `pass`.

## Findings
Emit per `schema/finding.schema.json`. Example ids:
- `M21.platform.fk_unenforced_on_vitess` — FK constraints declared but PlanetScale/Vitess won't enforce
  them (fail, severity 4, axis `both`, confidence `directional` static / `established` with Tier-1).
- `M21.platform.rls_off_supabase` — table exposed via Supabase API with RLS disabled (fail, severity 5,
  axis `design`, confidence `established` with Tier-1).
- `M21.platform.engine_version_old` — clearly-old engine major (warn, severity 3, axis `both`,
  confidence `directional`; no fabricated EOL date — cite vendor page or defer).
- `M21.platform.serverless_direct_pg` — direct long-lived PG connection from edge/serverless (warn,
  severity 4, axis `performance`; cross-ref M15).
Each finding: `evidence.observed` quotes the real config/DDL/version string verbatim (secrets redacted);
`verification.reproduce` is a runnable command above using `$DATABASE_URL`; `verification.method` is
`connection_introspect`, `schema_introspect`, or `manual_review`; `expected_impact` carries
`{axis, confidence, magnitude, rationale}` — banded, never a naked %.

## Honesty
- **No fabricated EOL dates, prices, or quotas — ever**, in findings or design recs. Cite the vendor's
  current page via `WebFetch` (quote it) or defer with `directional` and a "confirm on vendor page" note.
- Lock-in is a trade-off, not automatically a defect: name what you'd give up, don't moralize.
- Version "old" without a sourced EOL is `directional` and never caps. FK-unenforced caps only at sev 4
  (not 5) unless it directly enables orphan financial/auth rows. Unreachable platform → `needs_api`.