database-design
Master database design and schema decisions
Developers struggle with database choices and schema design pitfalls. This skill teaches decision frameworks for selecting databases, designing schemas, and optimizing queries based on context.
Download the skill ZIP
Upload in Claude
Go to Settings → Capabilities → Skills → Upload skill
Toggle on and start using
Test it
Using "database-design". I need to choose a database for a real-time chat application with 10,000 concurrent users, global distribution, and sub-50ms latency requirements.
Expected outcome:
For global real-time chat with strict latency requirements, consider Turso (edge SQLite) for presence and message metadata, combined with a primary PostgreSQL instance for durable storage. Turso provides edge deployment reducing latency, while PostgreSQL handles complex queries and transactions. Alternative: PlanetScale for MySQL compatibility with global branching.
Using "database-design". Should I normalize my user preferences table or store as JSONB?
Expected outcome:
Store as JSONB if: preferences are rarely queried individually, schema evolves frequently, and you always fetch the complete set. Normalize if: you need to query specific preferences in WHERE clauses, different preferences have different update frequencies, or you need foreign key constraints. Hybrid approach: JSONB for flexible preferences with a normalized table for frequently-filtered settings.
Security Audit
SafeAll static analyzer findings are false positives. The 'external_commands' detections are markdown code fence blocks (```) used for educational diagrams, not executable shell commands. The 'weak cryptographic algorithm' flags reference UUID/ULID discussions in documentation context. The schema_validator.py is a legitimate local Python script for Prisma schema validation. This is a documentation-only skill teaching database design principles.
Quality Score
What You Can Build
New project database setup
A startup founder building an MVP needs guidance on choosing between PostgreSQL, SQLite, or serverless options. The skill provides a decision tree based on scalability needs, budget, and deployment preferences.
Schema design review
A backend engineer designing a new feature needs help modeling user relationships, timestamps, and foreign key constraints. The skill reviews normalization trade-offs and relationship patterns.
Query performance troubleshooting
A developer experiencing slow queries needs to understand indexing strategies and N+1 problems. The skill explains EXPLAIN ANALYZE interpretation and composite index design.
Try These Prompts
I am building a {project_type} application with {expected_users} users. My budget is {budget_level} and I need {specific_requirements}. Based on the database selection guide, recommend the best database option and explain the trade-offs.Review my schema design for {table_name} table. I need to store {data_fields} with relationships to {related_tables}. Check if my approach follows normalization principles, has appropriate indexes, and uses the correct relationship types.My query for {query_description} is taking {execution_time}. Here is the EXPLAIN ANALYZE output: {explain_output}. Identify the bottleneck and recommend specific indexing or query restructuring strategies.I need to migrate from {current_schema} to {target_schema} with zero downtime. The table has {row_count} rows and serves {traffic_level} traffic. Design a migration strategy using the techniques from the migrations guide.Best Practices
- Always define created_at and updated_at timestamps using TIMESTAMPTZ for timezone awareness
- Use UUID or ULID primary keys for distributed systems to avoid enumeration attacks and enable offline ID generation
- Create composite indexes matching your most common query patterns with equality columns before range columns
Avoid
- Defaulting to PostgreSQL for simple applications where SQLite would suffice, adding unnecessary infrastructure complexity
- Creating indexes on every column without considering write performance impact and low-cardinality inefficiency
- Using SELECT * in production queries instead of explicitly selecting needed columns