database
Database - schema, indexes, migrations. Use when working with databases.
When & Why to Use This Skill
This Claude skill provides comprehensive support for database engineering, specializing in schema design, migration management, and performance tuning. Optimized for the Neon (Postgres) and Drizzle ORM stack, it ensures data integrity, prevents schema drift, and guides developers in building scalable, high-performance data architectures through rigorous indexing and constraint strategies.
Use Cases
- Schema Design & Modeling: Architecting robust database structures that align with business logic while ensuring long-term scalability and maintainability.
- Migration Management: Automating the creation and validation of migration files to maintain consistency across development, staging, and production environments.
- Performance Optimization: Identifying and implementing strategic indexes to resolve slow queries and prepare the database for 10x-100x traffic growth.
- Data Integrity & Constraints: Establishing strict database constraints and lifecycle policies (like soft deletes) to prevent invalid data states and reduce technical debt.
| name | database |
|---|---|
| description | Database - schema, indexes, migrations. Use when working with databases. |
Database Guideline
Tech Stack
- Database: Neon (Postgres)
- ORM: Drizzle
Non-Negotiables
- Migration files must exist, be complete, and be committed
- CI must fail if schema changes aren't represented by migrations
- No schema drift between environments
Context
The database schema is the foundation everything else is built on. A bad schema creates friction for every feature built on top of it. Schema changes are expensive and risky — it's worth getting the design right.
Consider not just "does the schema work?" but "does this schema make the right things easy?" Are the relationships correct? Are we storing data in ways that will be painful to query? Are we missing constraints that would prevent bugs?
Driving Questions
- If we were designing the schema from scratch, what would be different?
- Where are missing indexes causing slow queries we haven't noticed yet?
- What data relationships are awkward or incorrectly modeled?
- How does the schema handle data lifecycle (soft deletes, archival, retention)?
- What constraints are missing that would prevent invalid state?
- Where will the current schema hurt at 10x or 100x scale?