database-schema-designer

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:

1. Never DROP without backup — Always generate backup commands first
2. Always generate rollback — Every migration includes verified reversal
3. Test migrations on staging — Never run directly on production
4. Lock-aware design — Schema changes must consider lock duration
5. Data integrity first — Validate before and after every migration
6. 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:

• 1NF: Atomic columns, no repeating groups
• 2NF: No partial dependencies on composite keys
• 3NF: No transitive dependencies
• BCNF: Every determinant is a candidate key (when needed)
• Denormalize intentionally (document why, measure benefit)