home / skills / vudovn / antigravity-kit / database-design

database-design skill

safe

This skill helps you design scalable database schemas, choose databases and ORMs, and optimize indexing for performance.

npx playbooks add skill vudovn/antigravity-kit --skill database-design

Review the files below or copy the command above to add this skill to your agents.

Files (8)

SKILL.md

1.5 KB

---
name: database-design
description: Database design principles and decision-making. Schema design, indexing strategy, ORM selection, serverless databases.
allowed-tools: Read, Write, Edit, Glob, Grep
---

# Database Design

> **Learn to THINK, not copy SQL patterns.**

## 🎯 Selective Reading Rule

**Read ONLY files relevant to the request!** Check the content map, find what you need.

| File | Description | When to Read |
|------|-------------|--------------|
| `database-selection.md` | PostgreSQL vs Neon vs Turso vs SQLite | Choosing database |
| `orm-selection.md` | Drizzle vs Prisma vs Kysely | Choosing ORM |
| `schema-design.md` | Normalization, PKs, relationships | Designing schema |
| `indexing.md` | Index types, composite indexes | Performance tuning |
| `optimization.md` | N+1, EXPLAIN ANALYZE | Query optimization |
| `migrations.md` | Safe migrations, serverless DBs | Schema changes |

---

## ⚠️ Core Principle

- ASK user for database preferences when unclear
- Choose database/ORM based on CONTEXT
- Don't default to PostgreSQL for everything

---

## Decision Checklist

Before designing schema:

- [ ] Asked user about database preference?
- [ ] Chosen database for THIS context?
- [ ] Considered deployment environment?
- [ ] Planned index strategy?
- [ ] Defined relationship types?

---

## Anti-Patterns

❌ Default to PostgreSQL for simple apps (SQLite may suffice)
❌ Skip indexing
❌ Use SELECT * in production
❌ Store JSON when structured data is better
❌ Ignore N+1 queries

Overview

This skill teaches practical database design principles and decision-making for modern applications. It guides schema design, indexing strategies, ORM selection, and considerations for serverless databases. The goal is to help you think through trade-offs and choose solutions that match your context, not to copy patterns blindly.

How this skill works

It inspects the project context and asks targeted questions about scale, deployment, and data access patterns. Based on answers, it recommends a database type, a fitting ORM, a normalization approach, and an index plan. It also highlights anti-patterns and migration strategies for both traditional and serverless environments.

When to use it

Starting a new application and choosing a database and ORM
Refactoring schema or improving query performance
Planning migrations or moving to a serverless database
Designing relationships and primary key strategies
Before deploying to production to ensure indexes and queries are efficient

Best practices

Ask about constraints up front: expected scale, latency, ACID needs, and hosting model
Choose the simplest database that meets requirements (e.g., SQLite for simple apps, serverless DBs for ephemeral workloads)
Design normalized schemas for structured data; use JSON only when schema flexibility is required
Plan indexes for read patterns: add composite indexes for common multi-column filters and avoid over-indexing
Avoid SELECT * in production and proactively detect N+1 query patterns
Use safe, reversible migrations and test them against production-like data or backups

Example use cases

Recommend between PostgreSQL, Neon, Turso, or SQLite given traffic, cost, and hosting constraints
Select an ORM (Drizzle, Prisma, Kysely) based on type-safety needs, runtime environment, and migration support
Design normalized schema with proper PKs and relationship types (one-to-many, many-to-many) for an e-commerce app
Create an indexing strategy and query plan to remove N+1 issues and speed up critical endpoints
Plan safe migrations for a serverless database and outline rollback steps

FAQ

How do you pick an ORM?

Match ORM features to team needs: prefer type-safe query builders for strict typing, full-featured ORMs for batteries-included workflows, and lightweight libraries for simple projects.

When should I use JSON columns?

Use JSON for semi-structured or rapidly evolving fields where schema changes would be frequent; prefer normalized columns for core, query-critical data to enable indexing and constraints.