Postgres docker-compose and Drizzle ORM scaffolding (foundation layer)
juanjo adds the Docker Postgres setup and Drizzle ORM scaffolding that underpin the Supabase removal. The schema commit defines the full application data model in TypeScript - if you want to understand what juanjo/mike stores, `backend/src/db/schema.ts` is the file.
The infrastructure is straightforward. docker-compose.yml runs postgres:16-alpine on host port 54322, persisted via a named volume. An init script (db/init/01-extensions.sql) loads pgcrypto on first boot, which gen_random_uuid() depends on. The drizzle.config.ts points drizzle-kit at DATABASE_URL, outputs migrations to backend/drizzle/, and runs with strict: true.
The schema commit (267ec65) is where the substance is. backend/src/db/schema.ts covers the full application domain in 376 lines. Application tables: users, user_profiles, projects, project_subfolders, documents, document_versions, document_edits, chats, chat_messages, workflows, workflow_shares, tabular_reviews, tabular_cells, tabular_review_chats, tabular_review_chat_messages, hidden_workflows. Auth.js adapter tables: accounts, verification_tokens. The document_edits.status column enforces pending | accepted | rejected with a CHECK constraint; document_versions.source does the same for its six-value enum.
The generated backend/drizzle/0000_initial.sql is 252 lines: CREATE TABLE statements, btree indexes on the high-traffic join columns, and FK constraints. One FK (document_versions.document_id → documents.id) carries ON DELETE CASCADE.
The client.ts uses the postgres driver (not pg) with a single shared pool at max 10. A minor comment cleanup and a trailing-newline fix round out the five commits.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?