Engineering record — internal detail. The manual is authoritative for product behaviour.
Supabase → Neon migration
Historical: moving the datastore from Supabase Postgres to Neon, Supabase Auth to a first-party auth stack, and Supabase Storage to Cloudflare R2.
Scope
A five-phase migration off Supabase: Postgres to Neon, Supabase Auth to a first-party auth stack, Supabase Storage to Cloudflare R2, and PGMQ plus Vercel Cron to Trigger.dev. The design covers auth flows, storage operation mapping, background jobs, data migration, rollback and risks; the plan is a 40-plus-task, five-phase execution document.
Note
Design versus shipped implementation
The design specified NextAuth v5. The shipped dependency set carries Better Auth, not NextAuth, so the auth layer converged on a different choice than the plan recorded. Treat the plan as the migration history, not the current description.
What it changed
| Concern | Before | After |
|---|---|---|
| Database | Supabase Postgres | Neon Postgres |
| Database access | Supabase client helpers with RLS | Drizzle ORM over the Neon serverless driver |
| Auth | Supabase Auth | First-party auth (shipped as Better Auth) |
| Object storage | Supabase Storage | Cloudflare R2 with presigned URLs |
| Jobs | PGMQ + Vercel Cron | Trigger.dev |
Follow-through
The plan removes tenant policies from more than fifty schema files and rewrites the authenticated database wrapper, middleware, auth helpers and password-reset routes. The tenant boundary then moves from database policies into the application's organisation-scoped action layer — which is why the later security reviews focus on organisation-scoped getters and cross-org reference rejection.
Source records
- Design
- docs/superpowers/specs/2026-07-30-supabase-to-neon-migration-design.md
- Plan
- docs/superpowers/plans/2026-07-30-supabase-to-neon-migration-plan.md