# Phase 14: PostgreSQL Migration - Discussion Log

> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.

**Date:** 2026-04-04
**Phase:** 14-postgresql-migration
**Areas discussed:** Migration strategy, Data migration script, Test infrastructure, Docker Compose layout
**Mode:** --auto (all decisions auto-selected as recommended defaults)

---

## Migration Strategy

| Option | Description | Selected |
|--------|-------------|----------|
| Clean schema rewrite | Rewrite schema.ts using drizzle-orm/pg-core with fresh migration history | ✓ |
| Convert existing migrations | Transform SQLite migrations to Postgres equivalents | |
| Dual-dialect schema | Maintain both SQLite and Postgres schema definitions | |

**User's choice:** [auto] Clean schema rewrite (recommended default)
**Notes:** SQLite and Postgres dialects differ enough (type system, auto-increment vs serial, pragma vs native features) that converting migrations is error-prone. Fresh start is cleaner.

| Option | Description | Selected |
|--------|-------------|----------|
| Fresh Postgres migration history | New directory, archive SQLite migrations | ✓ |
| Convert SQLite migrations | Rewrite each .sql file for Postgres | |

**User's choice:** [auto] Fresh Postgres migration history (recommended default)
**Notes:** 10 existing SQLite migrations would need manual conversion. Starting fresh avoids dialect translation bugs.

---

## Data Migration Script

| Option | Description | Selected |
|--------|-------------|----------|
| Standalone TypeScript script | Reads SQLite, writes Postgres, one-time use | ✓ |
| Drizzle migration | Built into the migration pipeline | |
| SQL dump + import | pg_dump-style approach | |

**User's choice:** [auto] Standalone TypeScript script (recommended default)
**Notes:** One-time operation that doesn't belong in the migration pipeline. Script can handle type conversions explicitly.

---

## Test Infrastructure

| Option | Description | Selected |
|--------|-------------|----------|
| Per-test PGlite instance | Fresh database per test, migrations applied each time | ✓ |
| Shared PGlite with transaction rollback | One instance, wrap each test in a rolled-back transaction | |
| Shared PGlite with cleanup | One instance, truncate tables between tests | |

**User's choice:** [auto] Per-test PGlite instance (recommended default)
**Notes:** Matches current in-memory SQLite pattern. Avoids test pollution. PGlite is lightweight enough for per-test instances.

---

## Docker Compose Layout

| Option | Description | Selected |
|--------|-------------|----------|
| Separate dev compose file | docker-compose.dev.yml with Postgres for development | ✓ |
| Single compose with profiles | Use Docker Compose profiles for dev vs prod | |
| Extend existing compose | Add Postgres to the single docker-compose.yml | |

**User's choice:** [auto] Separate dev compose file (recommended default)
**Notes:** Separation of concerns. Production compose will also need Postgres eventually but with different configuration.

| Option | Description | Selected |
|--------|-------------|----------|
| PostgreSQL 16 | Latest stable release | ✓ |
| PostgreSQL 15 | Previous stable | |

**User's choice:** [auto] PostgreSQL 16 (recommended default)

---

## Claude's Discretion

- Drizzle Postgres driver choice (node-postgres vs postgres-js)
- PGlite configuration details
- Column type mapping specifics
- Migration script error handling
- Test driver choice for PGlite

## Deferred Ideas

None