Two Supabase projects, one of them named prod, and the site wrote to the other one
Decided
The frontend's NEXT_PUBLIC_SUPABASE_URL was repointed from wwcbbjcgoxjraiqcusjw to pevgijvcgqhdivdljjkh, and the second project was renamed from a bare ref to `novel-systems-site` so that the dashboard shows which is which without opening either.
What was actually wrong. The organisation holds two projects. novel-systems-prod is the backend's database — Prisma's schema, the tenant tables, the RLS policies, everything DATABASE_URL reaches. The other project holds the four *website intake* tables: leads, support_tickets, job_applications, audit_logs. These are different databases serving different codebases, and only one of them has ever had a table called support_tickets in it. Vercel's frontend project pointed at the first.
The symptom was Invalid path specified in request URL — PostgREST's answer when you ask for a table that is not there. It reads like a routing bug in our own code, which is why it survived. Nothing about it says "right server, wrong database", and the health endpoint reported database: configured throughout, because a URL was set and set is all it checked.
Why the name was the trap. A project named novel-systems-prod is the one you reach for when a variable is called SUPABASE_URL and the environment is Production. The name described its *tier*, not its *contents*, and there were two things in that tier. Renaming the second project to say what it holds costs nothing and removes the only signal that made the wrong choice look right.
The blast radius, which is the part worth recording. After the repoint the support_tickets table contained exactly one row — the verification ticket NS-91342. That is not a small dataset; that is the entire history. Every contact lead, every support ticket, every job application and every audit-log entry the live site had ever accepted was written to a database that had no such table, discarded, and reported to the visitor as accepted. /api/support logs not stored (…) at console.error on exactly this path, so the failure was recorded hundreds of times and read zero.
What would make this wrong. Consolidating both codebases onto one Supabase project would make this entry moot and is defensible — the split exists because the two were provisioned months apart, not because anything requires it. It would also mean the backend's service role and the site's service role become the same credential, which is the reason not to.