tia/drizzle

Tia — Database Migrations

This folder is source code and is committed to git. It is consumed by the deploy pipeline (pnpm db:migrate, run on container start — see Dockerfile).

Baseline reset — 2026-05-19

The project's first 16 migrations (0000–0015) plus a manual/ folder were hand-rolled SQL applied directly via the Dokploy database terminal. They were never run through Drizzle's migrator, so:

• prod had no __drizzle_migrations tracking table;
• the drizzle/ folder was gitignored, so migration SQL never reached the server;
• schema.ts had drifted well behind the real production schema.

To fix this we performed a Path A baseline reset:

1. pg_dump backup of prod taken and stored off-server.
2. drizzle-kit pull introspected the live prod schema (35 tables).
3. src/db/schema/*.ts was rewritten to match prod exactly.
4. Legacy migrations were archived to _archived_pre_baseline_2026-05-19/ (also retained in git history).
5. A single fresh baseline — 0000_baseline_prod_2026_05_19.sql — was generated and verified column-for-column against the introspected prod schema.
6. Prod's drizzle.__drizzle_migrations table was created and seeded with one row marking 0000_baseline_prod_2026_05_19 as already applied, so the migrator treats prod as up-to-date and runs nothing on the next deploy.

Normal workflow from here

# 1. Edit src/db/schema/*.ts
# 2. Generate a migration from the diff:
pnpm db:generate            # writes drizzle/000N_<name>.sql
# 3. Review the generated SQL by eye.
# 4. Apply locally against the dev DB:
pnpm db:migrate
# 5. Commit schema + migration together, then push.
#    Dokploy redeploys; the migrator applies it in prod on container start.

Hard rules

• Never edit a migration file after it has been pushed. Fix-forward with a new migration instead.
• Never run schema-changing SQL directly against prod. It becomes drift.
• The drizzle/ folder must stay out of .gitignore.

RLS policies

Five log tables (feeds, diapers_logs, sleeps, vaccinations, growth) plus children / family_members carry row-level-security policies in prod. These are not modelled in the pgTable definitions and are managed separately in the database. Drizzle migrations will not recreate them — keep that in mind if you ever rebuild the DB from scratch.