Converted and distributed by TomeVault — claim your Tome and manage your conversions.
Coder System Design DB Schema
Database schema design and migration safety rules for production systems. Use when this capability is needed.
Coder System Design DB Schema by tomevault-io · 73afee9
npx skillmds@latest add tomevault-io/coder-system-design-db-schema File contents
---name: coder-system-design-db-schemadescription: Database schema design and migration safety rules for production systems. Use when this capability is needed.---<when_to_use> <trigger>Designing relational schema for new services or major feature changes</trigger> <trigger>Planning schema evolution and data migrations in production</trigger> <trigger>Reviewing index/constraint strategy and multi-tenant data isolation</trigger></when_to_use><input_requirements> <required>Core entities and relationships</required> <required>Read/write access patterns and query shapes</required> <required>Data retention, audit, and compliance constraints</required> <required>Deployment constraints (downtime, lock tolerance, rollback)</required></input_requirements><design_principles> <principle priority="P0">Start normalized; denormalize only for measured bottlenecks</principle> <principle priority="P0">Enforce integrity in database using PK/FK/unique/check constraints</principle> <principle priority="P0">Design indexes from real query predicates and sort patterns</principle> <principle priority="P1">Use compatibility-first schema evolution via expand and contract</principle> <principle priority="P1">Treat tenant isolation as explicit schema and policy decision</principle> <principle priority="P1">Separate audit history needs from soft-delete convenience</principle></design_principles><decision_points> <item>Normalization vs denormalization based on read latency and write amplification tradeoff</item> <item>Tenant model: database-per-tenant vs schema-per-tenant vs shared-schema with tenant_id</item> <item>Deletion model: hard delete vs soft delete vs temporal/audit tables</item> <item>Key strategy: surrogate vs natural keys with interoperability constraints</item></decision_points><migration_safety_checklist> <item>Migration is split into expand, backfill, switch, and contract phases</item> <item>Lock impact and long-running DDL risk are analyzed before rollout</item> <item>Online index strategy is used where supported</item> <item>Backfill is batched, idempotent, and observable</item> <item>Rollback or roll-forward path is explicitly documented</item> <item>Post-migration validation queries are defined before deploy</item></migration_safety_checklist><quality_rules> <rule importance="critical">Do not perform breaking schema changes without compatibility window</rule> <rule importance="critical">Do not rely on app-level validation for integrity-critical constraints only</rule> <rule importance="high">Do not ship index changes without query-path rationale</rule> <rule importance="high">Do not run unbounded data backfill during peak load without controls</rule></quality_rules><do_not> <item importance="critical">Do not rename/drop hot-path columns and tables in same release as app switch</item> <item importance="high">Do not add broad indexes "just in case"</item> <item importance="high">Do not treat soft delete as complete audit solution</item></do_not><output_requirements> <requirement>Schema proposal with constraints and index rationale</requirement> <requirement>Phased migration plan with safety controls</requirement> <requirement>Verification SQL and rollback strategy</requirement> <requirement>Risks and operational caveats</requirement></output_requirements><references> <source url="https://www.postgresql.org/docs/16/sql-altertable.html">PostgreSQL ALTER TABLE</source> <source url="https://www.postgresql.org/docs/16/explicit-locking.html">PostgreSQL Explicit Locking</source> <source url="https://www.postgresql.org/docs/16/sql-createindex.html">PostgreSQL CREATE INDEX</source> <source url="https://www.postgresql.org/docs/16/indexes-multicolumn.html">PostgreSQL Multicolumn Indexes</source> <source url="https://www.postgresql.org/docs/16/indexes-partial.html">PostgreSQL Partial Indexes</source> <source url="https://www.postgresql.org/docs/16/ddl-rowsecurity.html">PostgreSQL Row Level Security</source> <source url="https://learn.microsoft.com/en-us/azure/azure-sql/database/saas-tenancy-app-design-patterns">Azure SQL SaaS Tenancy Patterns</source> <source url="https://martinfowler.com/articles/evodb.html">Evolutionary Database Design</source></references>---> Converted and distributed by [TomeVault](https://tomevault.io/claim/ozerohax) — claim your Tome and manage your conversions.<!-- tomevault:4.0:skill_md:2026-04-11 -->
tomevault-io/skills-registry/tree/main/ozerohax--assistagents--db-schema commit 73afee980c
Frequently asked questions
Run npx skillmds@latest add tomevault-io/coder-system-design-db-schema in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Database schema design and migration safety rules for production systems. Use when this capability is needed. It is listed under Coding & Dev Tools on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.