Supabase Auth
Postgres-native auth bundled with Supabase. Free, owned-data, integrates with RLS.
VISIT SUPABASE AUTHKey takeaway: If your data already lives in Supabase Postgres, this is the default and the alternatives need to justify themselves. Having auth.uid() available inside row-level security policies means authorisation is enforced at the database rather than in application code, which is a structural advantage no hosted vendor can match. The trade is that you build the account UI yourself.
Quick facts
- CategoryBundled with platform
- LanguageTypeScript
- PricingOpen source
- LicenseApache-2.0
- Created2020
- GitHub stars1.6k
- HIPAA-eligibleYes (BAA)
- SSO / SAMLLimited / paid
What it is
Supabase Auth is GoTrue (the open-source library) bundled into the Supabase platform. Email + password, social logins, magic links, MFA, anonymous auth. Tightly integrated with Postgres RLS, auth.uid() is available inside row-level security policies. Free with Supabase free tier.
Best for
- Apps already on Supabase where auth is one of several services
- Teams that want to own the user database
- Postgres + RLS workloads where auth.uid() is the policy primitive
- Cost-sensitive teams at any scale
When not to pick it
Skip Supabase Auth if your stack is not Supabase, using GoTrue standalone works but you lose the platform integration. Skip if you need pre-built UI components polished to Clerk's level.
My take
For Supabase-stack apps, this is the right answer by default. The integration with RLS is the differentiator. UI polish is the trade-off, you build it yourself or use Clerk on top.
Row-level security is the actual differentiator
Most auth products stop at proving who someone is and leave what they can see to your application layer. Supabase Auth issues a token that Postgres itself can read, so a row-level security policy can say a row belongs to auth.uid() and the database refuses to return it otherwise. That changes the failure mode entirely. A missing check in a route handler is no longer a data leak, because the query would have returned nothing anyway, and the same rule applies whether the request arrived through your server, the client SDK, or a direct PostgREST call. The discipline it demands is real: policies must be written and tested for every table, and a table with RLS enabled and no policy silently returns nothing, which is a confusing first hour. Once the habit sticks, it is the most defensible authorisation model available to a small team.
What you give up against Clerk
Supabase gives you the mechanics, not the screens. Sign-in, sign-up, password reset, email verification, MFA enrolment and the account settings page are yours to design and maintain, and the official UI helpers have never been the polished product Clerk sells. Organisation and member primitives for multi-tenant apps are also something you model yourself in Postgres, which is flexible but is work. Enterprise SSO and SAML are not the core story and sit behind higher plans, so a B2B product with serious enterprise requirements should look at WorkOS alongside it. Against all of that: the user table is in your database, you can join against it, you can back it up with everything else, and no per-active-user meter is running. For cost-sensitive products at any scale, and for anything where owning the data is a constraint rather than a preference, that is hard to argue with.
Frequently asked questions
Is Supabase Auth free?
The auth service is open source under Apache 2.0 and ships with every Supabase project, including the free tier. You pay for the Supabase platform rather than for authentication as a separate line item, which is a large part of why cost-sensitive teams keep landing on it. Running the underlying service standalone is possible but loses the platform integration.
Can I use Supabase Auth without the rest of Supabase?
Technically yes, the underlying service is open source and can run standalone, but you lose the reason to pick it. The value is the tight coupling to Postgres row-level security and the rest of the platform. If your database is elsewhere, Better Auth or Auth.js will give you a better standalone experience with less friction.
Supabase Auth or Clerk for a Next.js app?
Clerk if you want finished sign-in and profile components today and the per-active-user cost is acceptable. Supabase Auth if you are already on Supabase Postgres, want row-level security doing your authorisation, and are willing to build the account screens. Some teams run Clerk in front of Supabase data, but that leaves two sources of user truth to reconcile.
Links
Compare Supabase Auth side-by-side
Similar tools you should also consider
Clerk
TypeScript-first hosted auth with the cleanest developer experience in the category in 2026.
Read the take →Firebase Auth
Google's bundled auth, email, social, phone, anonymous. Generous free tier, locks you into Google.
Read the take →Better Auth
Newer TypeScript-first OSS auth library. Designed as the modern Auth.js alternative.
Read the take →If Supabase Auth is your pick, the next conversation is short
The 30-min call is where your auth choice becomes a real architecture, a migration plan if you are switching, and a price range you can take to your stakeholders. Describe your stack, your scale, your compliance constraints. I tell you whether Supabase Auth is genuinely your fit.