Skip to main content

​
Persistence Boundary

This repo inherits the useful part of the next-forge database philosophy, not the default provider stack. The useful part is:
  • keep database ownership inside @repo/database
  • keep auth/session ownership inside @repo/auth
  • keep apps importing package-owned boundaries instead of raw provider clients
This repo is Supabase-first and SQL-migration-driven. It is not currently a true ORM-abstracted system.

​
Current truth

  • packages/database is the data-plane boundary.
  • packages/auth owns request-scoped and browser-scoped Supabase auth helpers.
  • supabase/migrations is the schema source of truth.
  • many runtime surfaces still run through a mock-backed adapter.
What is missing today:
  • stable repository interfaces
  • a clean split between mock and Supabase adapters
  • an honest provider-agnostic contract that we can switch behind quickly

​
Go-forward rules

  • Put data access in packages/database.
  • Put auth/session helpers in packages/auth.
  • Do not import @supabase/supabase-js directly in apps for data-plane work.
  • Do not claim the repo is ORM-swappable until mock and Supabase implementations conform to the same repository interfaces.
  • When persistence changes, update the migration docs and the database package contract together.

​
Migration direction

The intended sequence is:
  1. define repository interfaces in packages/database
  2. split mock and Supabase adapters
  3. standardize root migration and type-generation scripts
  4. remove misleading Prisma leftovers from active guidance
  5. keep future provider or ORM changes contained inside @repo/database