elitan drops Supabase entirely, moves to Better Auth + Kysely over plain Postgres
This is the most consequential commit in elitan's run: a full replacement of Supabase as both auth layer and data access layer, touching nearly every backend route and the entire frontend auth surface. The fork now requires only Postgres.
backend/src/lib/supabase.ts is deleted. In its place: auth.ts initializing Better Auth, and a 468-line db.ts wrapping Kysely over a typed schema in backend/src/db/types.ts (260 lines of generated table types from npm run db:codegen). Every route under backend/src/routes/ gets rewritten - tabular.ts alone changes 357 lines, projects.ts 235, documents.ts 214. The cycle is: delete the Supabase client call, replace with a typed Kysely chain, confirm the filter conditions are preserved.
Frontend: frontend/src/lib/supabase.ts and supabase-server.ts are deleted. AuthContext.tsx and auth-client.ts now talk to Better Auth. The three Supabase env vars on the frontend side disappear entirely; NEXT_PUBLIC_API_BASE_URL is all that remains in .env.local.
Schema changes in schema.sql (107 lines) drop Supabase RLS/auth references in favor of a vanilla Postgres schema Better Auth manages directly.
Two follow-up micro-commits cleaned up db.ts: renaming KyselyCompatQuery to KyselyResultQuery, then renaming the exported instance from kysely to db. Both suggest the author was cementing conventions after the large mechanical pass landed.
The PR (#1) was Codex-authored and merged the same day. A 1374-line deletion hand-translated to Kysely is a realistic place for subtle filter conditions to be lost - particularly worth checking query filters in tabular.ts and projects.ts before relying on this in production.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?