Db platform fit
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.From its SKILL.md
npx -y skills add Hainrixz/claude-db --skill db-platform-fitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 19 stars19 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.7 KB, as published. Nobody here has run it
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.