“The shift was quiet. They'd been using supabase for weeks, mostly out of obligation. Then built-in auth with social login providers solved a problem they'd been routing around — and suddenly the friction of row Level Security policies that are hard to debug when they're wrong felt absurd. They couldn't go back.”
When I'm it's a tuesday evening, I want to build and iterate on their product's data layer without managing servers, so I can use Postgres features — not a lowest-common-denominator database API.
A full-stack developer or indie hacker who uses Supabase as their backend and thinks of it as their database, their auth layer, their file storage, and their API layer at once. They came from Firebase and wanted Postgres. Or they came from setting up their own Postgres and wanted the tooling. Either way they arrived at Supabase and found a backend they could move on from thinking about. They write SQL fluently. They use Row Level Security. They are deeply comfortable in the Supabase dashboard. They have strong feelings about their Supabase tables.
To build and iterate on their product's data layer without managing servers — reliably, without workarounds, and without becoming the team's single point of failure for supabase, leveraging Postgres database with Row Level Security.
A full-stack developer or indie hacker who trusts their setup. Build and iterate on their product's data layer without managing servers is reliable enough that they've stopped checking. RLS policy testing in the dashboard that simulates a specific user context. They've moved from configuring supabase to using it.
It's a Tuesday evening. They're adding a new feature: users can follow each other and see a feed of activity from people they follow. They need a new table, a join table, a few RLS policies, and a view that builds the feed query. They're in the Supabase dashboard. They're writing SQL. They have the table created. The RLS policies are almost right — they're going to test them with the SQL editor using two test user IDs before they trust them. The feature will be working by midnight.
Uses Supabase for 2–5 projects, ranging from side projects to production SaaS apps. Uses Supabase Auth with email and social providers. Uses Supabase Storage for user uploads. Has 8–30 tables with foreign keys, views, and stored functions. Uses Supabase's generated TypeScript types in their frontend code. Deploys on Vercel; Supabase is the only backend they manage. Has hit the free tier limits and upgraded. Has restored from a database backup once. Has been in the Supabase Discord more than they'd like to admit.
Two things you'd notice: they reference supabase in conversation without being asked, and they've built workflows on top of it that weren't in the original plan. edge functions for serverless compute has become part of their muscle memory. They're now focused on use Postgres features — not a lowest-common-denominator database API — a sign the basics are solved.
The trigger is specific: cold starts on Edge Functions that affect user-facing response times, combined with a high-stakes deadline. supabase fails them at exactly the wrong moment. Edge Function limitations meant they still needed a separate backend for anything compute-heavy. What makes it irreversible: they fundamentally believe the backend should feel like part of the product, not like infrastructure you manage, and supabase just proved it doesn't share that belief.
Pairs with `clerk-primary-user` for developers who use Clerk for auth and Supabase for the rest of the backend. Contrast with `planetscale-primary-user` for the full-backend-platform vs. MySQL-specialist tool philosophy. Use with `vercel-primary-user` for the full indie hacker deployment stack: Next.js + Supabase + Vercel.