Database Schema Designer
Run a structured schema review before migrations so your agent does not ship missing indexes, weak constraints, or unplanned denormalization.
Overview
Database Schema Designer is an agent skill most often used in Build (also Validate scope, Ship security) that runs a complete database schema design and review checklist.
Install
npx skills add https://github.com/softaworks/agent-toolkit --skill database-schema-designerWhat is this skill?
- Pre-design gates: requirements, access patterns, SQL vs NoSQL, scale, and read/write ratio
- Normalization checklist through 3NF plus documented denormalization exceptions
- Table design: PK strategy, data types, NOT NULL, unique/check constraints, UTC timestamps
- Relationship and foreign-key integrity patterns with indexing follow-through
- End-to-end schema design checklist usable as an agent-driven review pass
- Structured checklist spans pre-design, normalization (1NF–3NF), table design, relationships, and related review sections
Adoption & trust: 3.8k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to create tables and migrations without agreeing on access patterns, keys, constraints, and indexes, so production pain shows up later as slow queries and data bugs.
Who is it for?
Solo builders designing PostgreSQL, MySQL, or similar SQL schemas for a new feature or greenfield API.
Skip if: Pure document-store modeling with no tabular discipline, or teams that already have a signed-off ERD and automated schema governance.
When should I use this skill?
Designing or reviewing a SQL-oriented database schema, migrations, or ERD before implementation.
What do I get? / Deliverables
You get a reviewed schema plan with normalization, constraints, relationships, and indexing called out so migrations and application code align with how data is actually queried.
- Completed schema design checklist with gaps flagged
- Documented PK/FK, constraint, and indexing decisions
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Physical schema design is owned by the Build backend shelf, but the same checklist is useful when you scope data models in Validate and when you harden storage before Ship. Backend is canonical because the checklist covers tables, keys, foreign keys, indexes, and SQL normalization—the core persistence layer.
Where it fits
List entities, relationships, and expected read/write patterns before committing to a stack and ORM.
Walk the checklist while drafting migration files and constraint definitions for a new billing module.
Verify unique constraints, sensitive columns, and access-related keys before exposing new API surfaces.
How it compares
Use as a structured review checklist instead of one-shot “design my database” chat without criteria.
Common Questions / FAQ
Who is database-schema-designer for?
Indie developers and small teams who want an agent to walk through schema requirements, normalization, constraints, and relationships before writing migrations.
When should I use database-schema-designer?
In Validate when scoping entities and queries, in Build when defining tables and foreign keys, and before Ship when you want a last-pass schema sanity check.
Is database-schema-designer safe to install?
It is procedural documentation; confirm trust via the Security Audits panel on this page and avoid granting the agent production credentials during review-only tasks.
SKILL.md
READMESKILL.md - Database Schema Designer
# Database Schema Design Checklist Complete checklist for designing and reviewing database schemas. --- ## Pre-Design - [ ] **Requirements Gathered**: Understand data entities and relationships - [ ] **Access Patterns Identified**: Know how data will be queried - [ ] **SQL vs NoSQL Decision**: Chosen appropriate database type - [ ] **Scale Estimate**: Expected data volume and growth rate - [ ] **Read/Write Ratio**: Understand if read-heavy or write-heavy --- ## Normalization (SQL) - [ ] **1NF**: Atomic values, no repeating groups - [ ] **2NF**: No partial dependencies on composite keys - [ ] **3NF**: No transitive dependencies - [ ] **Denormalization Justified**: If denormalized, reason documented --- ## Table Design ### Primary Keys - [ ] **Primary Key Defined**: Every table has primary key - [ ] **Key Type Chosen**: INT auto-increment or UUID - [ ] **Meaningful Keys Avoided**: Not using email/username as PK ### Data Types - [ ] **Appropriate Types**: Correct data types for each column - [ ] **String Sizes**: VARCHAR sized appropriately - [ ] **Numeric Precision**: DECIMAL for money, INT for counts - [ ] **Dates in UTC**: TIMESTAMP for datetime columns ### Constraints - [ ] **NOT NULL**: Required columns marked NOT NULL - [ ] **Unique Constraints**: Unique columns (email, username) - [ ] **Check Constraints**: Validation rules (price >= 0) - [ ] **Default Values**: Sensible defaults where appropriate --- ## Relationships ### Foreign Keys - [ ] **Foreign Keys Defined**: All relationships have FK constraints - [ ] **ON DELETE Strategy**: CASCADE, RESTRICT, SET NULL chosen - [ ] **ON UPDATE Strategy**: Usually CASCADE - [ ] **Indexes on Foreign Keys**: All FKs are indexed ### Relationship Types - [ ] **One-to-Many**: Modeled correctly - [ ] **Many-to-Many**: Junction table created - [ ] **Self-Referencing**: Parent-child relationships handled - [ ] **Polymorphic**: Strategy chosen (separate FKs or type+id) --- ## Indexing ### Index Strategy - [ ] **Primary Key Indexed**: Automatic, verify - [ ] **Foreign Keys Indexed**: All FKs have indexes - [ ] **WHERE Columns**: Columns in WHERE clauses indexed - [ ] **ORDER BY Columns**: Sort columns indexed - [ ] **Composite Indexes**: Multi-column queries optimized - [ ] **Column Order**: Most selective column first ### Index Limits - [ ] **Not Over-Indexed**: Only necessary indexes - [ ] **Index Maintenance**: Aware of write impact --- ## Performance - [ ] **Joins Optimized**: N+1 queries avoided - [ ] **SELECT * Avoided**: Only fetch needed columns - [ ] **Pagination**: LIMIT/OFFSET or cursor-based - [ ] **Aggregations**: Pre-calculated for expensive queries --- ## Migrations - [ ] **Backward Compatible**: New columns nullable initially - [ ] **Up and Down**: Rollback scripts provided - [ ] **Data Migrations Separate**: Schema vs data separated - [ ] **Tested on Staging**: Migrations tested --- ## Security - [ ] **Least Privilege**: Minimal database permissions - [ ] **Separate Accounts**: Read-only vs read-write - [ ] **Sensitive Data**: Passwords hashed, PII encrypted - [ ] **Parameterized Queries**: SQL injection prevented --- ## Documentation - [ ] **ERD Created**: Entity-relationship diagram - [ ] **Schema Documented**: Column descriptions - [ ] **Indexes Documented**: Why each index exists - [ ] **Migration History**: Changelog of changes # Database Schema Designer A comprehensive skill for designing production-ready database schemas with built-in best practices for both SQL and NoSQL databases. ## Purpose The Database Schema Designer skill helps you create robust, scalable database schemas by providing: - **Normalization guidance** - Apply proper normal forms (1NF, 2NF, 3NF) to eliminate data redundancy - **Indexing strategies** - Optimize query performance with the right indexes - **Migration patterns** - Evolve schemas safely with reversible, zero-downtime migrations - **Constraint design** - Ensure data integrity with proper foreign