Database overview

Baseleg uses Cloudflare D1 as the initial relational database, with Drizzle as the query/migration toolkit.

This document describes how the repo is structured so the data owner can expand it safely without breaking architecture boundaries.

Key rules

• UI routes/pages must not import Drizzle schema or repository implementations.
• Application packages must not depend on infrastructure implementations directly.
• Infrastructure owns D1/Drizzle wiring and repository implementations.
• Schema changes must ship with migrations.

Repo structure

• db/schema/ — canonical schema “source of truth” (placeholders today)
• db/migrations/ — SQL migration files (generated/maintained as the schema evolves)
• db/seeds/ — seed scripts/data for local/dev environments
• packages/infrastructure/db/ — Drizzle + D1 wiring (implementation detail)
• packages/infrastructure/repositories/ — repository implementations (DB-backed)

Suggested conventions (starting point)

These are conventions to adopt as we add real schema:

• One schema entrypoint per bounded context, e.g.:
  • db/schema/people.ts
  • db/schema/aircraft.ts
  • db/schema/scheduling.ts
• Migrations are append-only and ordered.
• Prefer explicit foreign keys for cross-table relationships.
• Keep “reporting” queries out of domain/application; implement in infrastructure behind ports.

Expansion roadmap (data owner)

1. Define first tables for the v1 spine:
   • People
   • Aircraft
   • Scheduling (bookings)
2. Add minimal indexes for core queries (list + overlap checks).
3. Add seed data that supports UI demos and test fixtures.
4. Add a drizzle.config.ts and a migration flow (when we’re ready to wire D1 locally/CI).