db-platform-fit
Skill22 starsChanged 5 months agoMITView on GitHub
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.
In this repository36 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- auditSkill
- checklistSkill
- db-antipatternsSkill
- db-concurrencySkill
- db-connection-poolingSkill
- db-constraintsSkill
- db-defaults-generatedSkill
- db-engine-selectionSkill
- db-index-hygieneSkill
- db-indexingSkill
- db-keysSkill
- db-migration-safetySkill
- db-multitenancySkill
- db-namingSkill
- db-normalizationSkill
- db-orchestratorSkill
- db-partitioning-shardingSkill
- db-query-patternsSkill
- db-referential-integritySkill
- db-replicas-viewsSkill
- db-security-accessSkill
- db-specialized-fitSkill
- db-storage-bloatSkill
- db-temporal-historySkill
- db-types-precisionSkill
- designSkill
- explainSkill
- fixSkill
- introspectSkill
- migrateSkill
- nextSkill
- scoreSkill
- seedSkill
- stack-detectSkill
- startSkill
The file
Files
<!-- Copyright (c) 2026 Enrique Rocha (@soyenriquerocha) · tododeia.com · id er-f37b7121 -->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
- 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. WithWebFetchyou MAY cite the vendor's published version page; quote it, don't paraphrase a number you can't source. - 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.
- 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_CHECKSawareness. → design + performance, sev 4 when FKs are declared but unenforceable. - Cloudflare D1 / SQLite — FKs exist but
PRAGMA foreign_keysmust 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.
- 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
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();andSHOW server_version;. - MySQL/PlanetScale:
SELECT VERSION();andSELECT @@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';andpg_policies. - D1/SQLite:
PRAGMA foreign_keys;. When the engine/platform isn't reachable →needs_api, never a falsepass.
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, axisboth, confidencedirectionalstatic /establishedwith Tier-1).M21.platform.rls_off_supabase— table exposed via Supabase API with RLS disabled (fail, severity 5, axisdesign, confidenceestablishedwith Tier-1).M21.platform.engine_version_old— clearly-old engine major (warn, severity 3, axisboth, confidencedirectional; 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, axisperformance; cross-ref M15). Each finding:evidence.observedquotes the real config/DDL/version string verbatim (secrets redacted);verification.reproduceis a runnable command above using$DATABASE_URL;verification.methodisconnection_introspect,schema_introspect, ormanual_review;expected_impactcarries{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 withdirectionaland 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
directionaland never caps. FK-unenforced caps only at sev 4 (not 5) unless it directly enables orphan financial/auth rows. Unreachable platform →needs_api.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

