| name | database-schema-designer |
| description | Design production-ready database schemas for SQL and NoSQL databases. Covers normalization, indexing strategy, migration management with rollback safety, query optimization, and multi-tenant patterns. Supports PostgreSQL, MySQL, SQLite, MongoDB, and Vitess. |
| version | 1.0.0 |
| platforms | ["openclaw","claude","codex","cursor","gemini","copilot","opencode","windsurf"] |
| author | {"name":"Skill Foundry (Forge)","source":"PlanetScale Database Skills, Supabase Agent Skills, softaworks/agent-toolkit"} |
| license | MIT |
| risk_tier | L2 |
| tags | ["database","schema","sql","nosql","postgres","mysql","migration","optimization","design"] |
| requires | {"binaries":[]} |
Database Schema Designer
Design production-ready database schemas with built-in best practices.
Covering SQL normalization, indexing strategy, migration management with
safe rollback patterns, query optimization, and multi-tenant architecture
patterns across PostgreSQL, MySQL, SQLite, MongoDB, and Vitess.
When to Use This Skill
Use this skill when:
- Designing a new database schema from scratch
- Reviewing an existing schema for performance or correctness
- Planning a database migration with safe rollback
- Optimizing slow queries on a production database
- Converting between database engines (MySQL → PostgreSQL, etc.)
- Designing multi-tenant data architectures
- Any request like "design a schema for X", "review my database",
"optimize this query", "create migrations", "normalize this table"
Safety Rules (Risk Tier L2)
Database operations can be destructive. This skill enforces:
- Never DROP without backup — Always generate backup commands first
- Always generate rollback — Every migration includes verified reversal
- Test migrations on staging — Never run directly on production
- Lock-aware design — Schema changes must consider lock duration
- Data integrity first — Validate before and after every migration
- No data loss — Backfill before dropping columns, migrate before deleting
Design Methodology
Phase 1: Domain Modeling
Start with entities, not tables. Map the domain before writing DDL:
DOMAIN CANVAS:
├── Entities: What things exist? (User, Order, Product, Invoice)
├── Relationships: How do they connect? (one-to-many, many-to-many)
├── Attributes: What properties do they have?
├── Constraints: What must always be true?
├── Access Patterns: What queries will run most often?
└── Growth Projections: How many rows? At what rate?
Phase 2: Schema Design — SQL
Normalization checklist:
