How do I install the Managing Drizzle Migrations skill?

Run npx skillmds@latest add jovandyaz/managing-drizzle-migrations in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Managing Drizzle Migrations safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Managing Drizzle Migrations?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Managing Drizzle Migrations free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Managing Drizzle Migrations?

jovandyaz (@jovandyaz) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Managing Drizzle Migrations by jovandyaz

Name: Managing Drizzle Migrations
Author: jovandyaz

Managing Drizzle Migrations

Guides Drizzle schema changes in Knowtis — generate-commit-migrate workflow, the never-push rule, deploy-time application, baselines, and zero-downtime patterns. Use when adding/changing a column, table, index, or enum, when asked "how do I change the schema", "agregar una columna", "migración", or when migration errors appear (42710, tracking table missing). Not for querying data (use investigating-postgres).

jovandyaz Updated Sep 17, 2026

File contents

Managing Drizzle migrations

Migrations (generate + migrate) are the single source of truth for the Knowtis schema. Full runbook: references/migrations-runbook.md.

The rule that matters most

Never drizzle-kit push against shared dev or prod databases. push leaves no migration history — it is what caused the schema-drift problems migrations were adopted to fix. push is acceptable only on throwaway local experiments.

Day-to-day workflow

# 1. Edit schema under apps/api/src/database/schema/
# 2. Generate the migration (repo root):
pnpm db:generate            # -> apps/api/drizzle/NNNN_*.sql + meta snapshot
# 3. Commit the .sql + meta/ changes. Never edit an applied migration.
# 4. Apply locally:
pnpm db:migrate:run

Production application — hands-off

Railway's pre-deploy command (railway.toml) is the only production migrator: pnpm exec tsx apps/api/src/database/migrate.ts runs between build and release with the service's own DATABASE_URL, takes a Postgres advisory lock, and aborts the deploy on failure. CI applies committed migrations only to its disposable test database; never migrate production manually.

Zero-downtime changes

Expand/contract for anything not backward-compatible with running code:

Expand — add nullable column / new table (deploy).
Backfill — populate (migration or job).
Contract — enforce NOT NULL / drop old column (later deploy).

Additive columns with a DEFAULT are safe in one step.

When migrate fails on an existing DB (e.g. `42710 enum already exists`)

The DB was push-managed and has no drizzle.__drizzle_migrations tracking table. First verify that its live schema is equivalent to the migration range being recorded; abort on any mismatch because baseline records hashes without applying DDL. Only then run pnpm db:baseline (schema current) or pnpm db:baseline <migration_tag> (record through that tag). Dev and prod are already tracked — this applies only to adopting a new push-managed database.

---name: managing-drizzle-migrationsdescription: Guides Drizzle schema changes in Knowtis — generate-commit-migrate workflow, the never-push rule, deploy-time application, baselines, and zero-downtime patterns. Use when adding/changing a column, table, index, or enum, when asked "how do I change the schema", "agregar una columna", "migración", or when migration errors appear (42710, tracking table missing). Not for querying data (use investigating-postgres).license: MIT---# Managing Drizzle migrationsMigrations (`generate` + `migrate`) are the single source of truth for the Knowtis schema. Full runbook: [references/migrations-runbook.md](references/migrations-runbook.md).## The rule that matters most**Never `drizzle-kit push` against shared dev or prod databases.** `push` leaves no migration history — it is what caused the schema-drift problems migrations were adopted to fix. `push` is acceptable only on throwaway local experiments.## Day-to-day workflow```bash# 1. Edit schema under apps/api/src/database/schema/# 2. Generate the migration (repo root):pnpm db:generate # -> apps/api/drizzle/NNNN_*.sql + meta snapshot# 3. Commit the .sql + meta/ changes. Never edit an applied migration.# 4. Apply locally:pnpm db:migrate:run```## Production application — hands-offRailway's pre-deploy command (`railway.toml`) is the only production migrator: `pnpm exec tsx apps/api/src/database/migrate.ts` runs between build and release with the service's own `DATABASE_URL`, takes a Postgres advisory lock, and aborts the deploy on failure. CI applies committed migrations only to its disposable test database; never migrate production manually.## Zero-downtime changesExpand/contract for anything not backward-compatible with running code:1. **Expand** — add nullable column / new table (deploy).2. **Backfill** — populate (migration or job).3. **Contract** — enforce `NOT NULL` / drop old column (later deploy).Additive columns with a `DEFAULT` are safe in one step.## When migrate fails on an existing DB (e.g. `42710 enum already exists`)The DB was push-managed and has no `drizzle.__drizzle_migrations` tracking table. First verify that its live schema is equivalent to the migration range being recorded; abort on any mismatch because baseline records hashes without applying DDL. Only then run `pnpm db:baseline` (schema current) or `pnpm db:baseline <migration_tag>` (record through that tag). Dev and prod are already tracked — this applies only to adopting a new push-managed database.

Frequently asked questions