Design Efficient Database Schemas

This skill teaches database design reasoning rather than copying SQL patterns, organized around a selective-reading map so only the relevant reference file is consulted: database-selection.md (PostgreSQL vs Neon vs Turso vs SQLite) when choosing a database, orm-selection.md (Drizzle vs Prisma vs Kysely) when choosing an ORM, schema-design.md (normalization, primary keys, relationships) when designing a schema, indexing.md (index types, composite indexes) for performance tuning, optimization.md (N+1 queries, EXPLAIN ANALYZE) for query optimization, and migrations.md (safe migrations, serverless databases) for schema changes.

Its core principle is to ask the user about database preferences when unclear and choose the database/ORM based on context rather than defaulting to PostgreSQL for everything. Its decision checklist before designing a schema: has the user's database preference been asked about, has a database been chosen for this specific context, has the deployment environment been considered, is there an index strategy, and are relationship types defined.

Its anti-patterns: defaulting to PostgreSQL for simple apps where SQLite may suffice, skipping indexing, using SELECT * in production, storing JSON when structured data would be better, and ignoring N+1 queries.

Use this skill when choosing a database or ORM, designing a schema, planning an indexing strategy, optimizing queries, or planning schema migrations.

Inputs: a database design task - technology selection, schema design, indexing, query optimization, or migration planning - plus the deployment context and user preferences.

Outputs: a context-appropriate database/ORM choice, a normalized schema with defined relationships, an indexing strategy, and safe migration guidance - avoiding common anti-patterns like defaulting to PostgreSQL or skipping indexes.

PostgreSQL, Neon, Turso, SQLite, Drizzle, Prisma, Kysely; bundled reference files database-selection.md, orm-selection.md, schema-design.md, indexing.md, optimization.md, and migrations.md.

Developers designing a database schema or choosing database/ORM technology who want context-driven reasoning instead of defaulting to one stack for every project.