Drizzle ORM migration with dual MySQL/PostgreSQL support

[dnplkndll]

Summary

Complete migration from raw SQL (TypedDB/ConfiguredRepo) to Drizzle ORM with full dual-dialect support for MySQL and PostgreSQL.

This supersedes PR #17 (Kysely migrations) by providing the same self-hosting database migration capability, plus a full ORM layer.

What's included

• 98/101 repository classes migrated to Drizzle ORM query builder (97% coverage)
  • 3 intentionally kept on TypedDB: AttendanceRepo (raw analytics SQL), ReportRepo (generic SQL runner), MembershipRepo in doing module (cross-module read-only)
• Dual-dialect schema definitions — src/db/schema/ (MySQL) and src/db/schema/pg/ (PostgreSQL), with a runtime resolver.ts that returns the correct schema based on DB_DIALECT env var
• drizzle-kit migrations — generated SQL files in drizzle/mysql/ and drizzle/postgresql/ for all 6 modules (membership, attendance, content, giving, messaging, doing)
• Programmatic migration runner (tools/migrate.ts) — applies pending migrations per module, supports --status flag
• Replaced tools/dbScripts/ DDL — all CREATE TABLE SQL files removed; DDL now managed by drizzle-kit migrations. Demo data and stored procs retained.
• initdb.ts rewritten — uses drizzle-orm migrators instead of raw SQL file iteration. MySQL→PG translation simplified to DML-only conversions.
• initdb.sh updated — Helm hook script reads drizzle migration SQL files directly (no tsx needed in prod)
• 299 integration tests across 6 test suites, all passing on both MySQL and PostgreSQL
• CI workflow (.github/workflows/test.yml) — lint, typecheck, and integration tests against both MySQL and PostgreSQL

Architecture

DB_DIALECT=mysql|postgres (env var, default: mysql)
    ↓
src/db/schema/resolver.ts → returns dialect-correct table definitions
    ↓
src/db/drizzle.ts → lazy-creates drizzle instances per module
    ↓
DrizzleRepo / GlobalDrizzleRepo → base classes with CRUD, soft-delete, dialect-aware executeRows()
    ↓
Per-module repos (98 classes) → use query builder, with raw SQL only for complex analytics

3-tier base class hierarchy:

• BaseDrizzleRepo — core: executeRows(), convertToModel()
• DrizzleRepo (extends Base) — for tables with id + churchId: load(), loadAll(), save(), delete(), optional softDelete
• GlobalDrizzleRepo (extends Base) — for tables with id only (no churchId): bible data, OAuth entities

Breaking changes

• DB_DIALECT env var required for PostgreSQL (defaults to mysql for backward compatibility)
• Per-module *_CONNECTION_STRING env vars now required (e.g., MEMBERSHIP_CONNECTION_STRING)
• tools/dbScripts/ no longer contains CREATE TABLE SQL — use npm run migrate or npm run initdb instead

New npm scripts

Script	Description
npm run migrate	Apply pending drizzle-kit migrations (all modules)
npm run migrate:status	Show applied/pending migration status
npm run migrate:generate	Generate migration for DB_MODULE (requires DB_MODULE env var)
npm run migrate:generate:all	Generate migrations for all modules, both dialects
npm run initdb -- --schema-only	Create tables without stored procs or demo data

Known limitations

• Schema defines events.registrationEnabled and events.capacity columns not yet in production DB
• devices schema includes contentType/contentId columns (may only exist in deviceContents table)
• contentProviderAuths table defined in schema but may not exist in production
• PostgreSQL stored procs (cleanup, updateConversationStats, deleteForChurch) are handled in application code, not as DB procedures

Test plan

• 299 integration tests passing (MySQL)
• 299 integration tests passing (PostgreSQL)
• TypeScript typecheck clean (tsc --noEmit)
• npm run initdb works on fresh MySQL database
• npm run initdb works on fresh PostgreSQL database
• Helm deployment verified on MySQL (b1-test namespace)
• Helm deployment verified on PostgreSQL (b1-postgres namespace)
• docker compose up local dev workflow verified

🤖 Generated with Claude Code

[dnplkndll]

@stephen-dahl I saw you where working on DB migrations with Kysely on #17
I added the migrations here. My goal was an option to use the pg stack I am more familiar writing.

[stephen-dahl]

@stephen-dahl I saw you where working on DB migrations with Kysely on #17 I added the migrations here. My goal was an option to use the pg stack I am more familiar writing.

Ya I haven't been happy with any of the ORMs I have used in the past including Drizzle. Kysely looks like I will be happy with it but @jzongker is the decision maker. So far I am just the guy throwing way too many library and refactor ideas at him.

Overall, I would say this MR is way too big and would take days to properly review, but it does give @jzongker a good idea of another ORM option.

[jzongker]

I'm just getting comfortable with the idea of switching to Kysely. Switching to a full ORM is going to be too big of a change.

I just switched LessonsApi over to Kysely this weekend and it'll go live in a few hours. This is both migration scripts and all of the repository code. Assuming no major issues come from this, I think we can switch the main API to Kysely immediately after Easter.