# Clerk vs Supabase Auth: which should your SaaS use?

> Clerk vs Supabase Auth compared: free limits, sign-in methods, teams, prebuilt UI, where users live, RLS, lock-in, and where Better Auth fits.

Source: https://shipanysaas-demo.vercel.app/blog/clerk-vs-supabase-auth
Published: 2026-10-18 · Updated: 2026-10-18

Clerk vs Supabase comes down to where your users live. Clerk is a hosted service with prebuilt sign-in and organization components, free up to 50,000 monthly retained users. Supabase Auth keeps users in your Postgres database, where row level security reads them directly, free up to 50,000 monthly active users. Clerk saves UI work; Supabase Auth saves moving parts.

Both are good. The right one depends on whether your app's data already lives in Supabase, whether you need teams on day one, and how much sign-in UI you want to build. Below: a side-by-side table, what each costs as you grow, sign-in methods, organizations, UI, how each works with Supabase RLS, lock-in, and a short take on Better Auth vs Supabase. Prices are as of October 2026, from each company's pricing page.

## Clerk vs Supabase Auth at a glance

| | Clerk | Supabase Auth |
| --- | --- | --- |
| Free tier | Hobby: 50,000 monthly retained users per app | Free: 50,000 monthly active users, 2 active projects |
| First paid plan | Pro: $25/mo ($20/mo billed yearly), 50,000 users included, then from $0.02 per user | Pro: from $25/mo, 100,000 users included, then $0.00325 per user |
| Sign-in methods | Password, magic links, email codes, up to 3 social connections on Hobby; SMS, passkeys and MFA from Pro | Password, magic link, one-time codes, phone, social OAuth, anonymous, passkeys (experimental); SAML SSO from Pro |
| Organizations and teams | Built in: roles, invitations, verified domains | Not built in: you model teams as tables |
| Prebuilt UI | Components such as `<SignIn />`, `<UserButton />`, `<OrganizationSwitcher />` | UI Library blocks you install into your codebase and edit |
| Where users live | Clerk's service | The `auth` schema of your own Postgres database |
| Row level security | Through Supabase's third-party auth integration, reading claims from the Clerk token | Native: `auth.uid()` and `auth.jwt()` in policies |
| Lock-in | Users and sessions sit with Clerk | Data is in Postgres; auth flows are Supabase's |

Sources: [clerk.com/pricing](https://clerk.com/pricing) and [supabase.com/pricing](https://supabase.com/pricing). One catch on Clerk's free plan: passkeys, MFA and SMS codes start on Pro. Supabase includes basic (authenticator app) MFA on every plan, and phone MFA is a $75/mo add-on for the first project.

## How much do Clerk and Supabase Auth cost?

Both are free for most early SaaS apps, and both Pro plans start at $25 a month. The difference shows at scale.

They also count users differently. Clerk bills monthly retained users, which it defines as "a user who visits your app in a given month at least one day after signing up". Someone who signs up and never returns doesn't count. Supabase bills monthly active users.

At 100,000 users a month:

- **Clerk Pro:** $25 plus 50,000 extra users at $0.02 is about **$1,025 a month** for auth.
- **Supabase Pro:** 100,000 users are included in the plan, which starts at **$25 a month** and also covers your database, storage and functions within its quotas.

If you use Clerk with a Supabase database, Supabase also counts those users as third-party MAUs: 50,000 included on Free, 100,000 on Pro, then $0.00325 each. Clerk's organizations add their own meter: 100 monthly retained organizations are included per app, then from $1 a month each. For the full Supabase bill, see [Supabase pricing explained](https://shipanysaas-demo.vercel.app/blog/supabase-pricing).

## Which sign-in methods does each support?

Both cover email and password, magic links and social login. Supabase includes more methods on its free plan; Clerk keeps passkeys and MFA for paid plans.

**Clerk's Hobby plan** includes usernames and passwords, magic links, email codes and up to 3 social connections. SMS codes, passkeys, biometric sign-in and MFA start on Pro. Enterprise SSO (SAML or OIDC) includes one connection on Pro, then $75 a month per extra connection.

**Supabase Auth** lists password, magic link, one-time password, social login and SSO in its [Auth docs](https://supabase.com/docs/guides/auth). Social login covers 19 named providers plus custom OAuth2 or OIDC ones. Phone sign-in works with MessageBird, Twilio or Vonage. Anonymous sign-ins come with every plan. SAML 2.0 SSO starts on Pro, with 50 SSO users included and $0.015 each after that. Passkeys are newer: Supabase marks them experimental, they need `@supabase/supabase-js` 2.105.0 or later, and you opt in on the client. The [Supabase passkeys guide](https://shipanysaas-demo.vercel.app/blog/nextjs-supabase-passkeys) and the [magic link guide](https://shipanysaas-demo.vercel.app/blog/nextjs-supabase-magic-link) show both flows in a Next.js app.

## Organizations and teams

Clerk has organizations built in. Supabase Auth has no organizations feature, so teams are tables you design and protect with row level security.

Clerk Organizations have default `admin` and `member` roles and invitations with a role attached. The free B2B tier allows up to 20 members per organization. The Enhanced B2B add-on, $100/mo ($85/mo billed yearly), removes the member limit and adds custom roles and verified domains, which invite people automatically by email domain. Components like `<OrganizationSwitcher />` and `<InviteMembersButton />` give you the UI.

With Supabase you build it: an accounts table, a memberships table with roles, an invitations table, and policies that check membership on every query. That is more work, but the rules live next to the data, in SQL you can test. [Multi-tenant SaaS: teams, roles and invitations](https://shipanysaas-demo.vercel.app/blog/multi-tenant-saas-teams-roles-invitations) walks through the design.

## Prebuilt UI

Clerk gives you finished components. Supabase gives you starter code to own.

Clerk's Next.js components include `<SignIn />`, `<SignUp />`, `<UserButton />`, `<UserProfile />`, `<OrganizationProfile />` and a billing `<PricingTable />`. Drop them in and the flows work, with Clerk branding until you're on Pro.

Supabase's UI Library has blocks such as password-based auth for Next.js, installed with `npx shadcn@latest add @supabase/password-based-auth-nextjs`. It writes sign-up, login, forgot-password and update-password pages into your project, and you edit them like any other file.

## Where your users live, and how RLS works

This is the biggest technical difference between Supabase Auth and Clerk.

Supabase Auth "uses your project's Postgres database under the hood", storing users in a special schema. Your tables can reference `auth.users`, a trigger can create a profile on sign-up, and policies can read the signed-in user directly:

```sql
create policy "Users read their own notes"
on public.notes for select
to authenticated
using ((select auth.uid()) = user_id);
```

Clerk keeps users on its own service. To use Clerk with Supabase, you add Clerk as a [third-party auth provider](https://supabase.com/docs/guides/auth/third-party/clerk) in Supabase. Clerk's session tokens must carry a `role` claim set to `authenticated`, and policies read the Clerk user id from the token's `sub` claim. Clerk user ids are strings, so the column is `text`, not a `uuid` foreign key to `auth.users`:

```sql
create table public.tasks (
  id bigint generated always as identity primary key,
  name text not null,
  user_id text not null default auth.jwt()->>'sub'
);

create policy "Users read their own tasks"
on public.tasks for select
to authenticated
using ((select auth.jwt()->>'sub') = user_id);
```

On the client, the Supabase client gets an `accessToken()` function that returns `session?.getToken()` from Clerk. The older approach, sharing Supabase's JWT secret with a Clerk JWT template, has been deprecated since 1 April 2025.

If you need user data in your own tables, such as names for a member list, Clerk recommends reading it from the session token where you can, and syncing with webhooks only when you must. Its docs warn that webhook deliveries "are not guaranteed", and that events "can also arrive out of order or more than once", so your sync code has to cope with both.

## Lock-in

Both have some. With Supabase Auth, users, sessions and your data are rows in Postgres that you can query, back up and migrate. The sign-in flows and token format are Supabase's. With Clerk, the user records, sessions and organizations live at Clerk, and your tables point at Clerk ids. Leaving means exporting users and replacing every component and token check. Neither is a trap, but moving from Clerk is the bigger job.

## Better Auth vs Supabase Auth

Better Auth is the third option people compare. It is an MIT-licensed TypeScript authentication framework that you run inside your own app, with your own database.

From [its docs](https://www.better-auth.com/docs/introduction), Better Auth works with PostgreSQL, MySQL and SQLite, has adapters for Drizzle, Prisma and MongoDB, and generates the schema with its CLI. Features come as plugins: an organization plugin (owner, admin and member roles, invitations, teams, 100 members per organization by default, configurable), passkeys (built on SimpleWebAuthn), two-factor, magic link, email OTP and SSO. The library is free; you pay for the server and database you run it on.

You can point Better Auth at a Supabase Postgres database. RLS is the catch: Better Auth isn't one of Supabase's first-class third-party providers (Clerk, Firebase Auth, Auth0, AWS Cognito and WorkOS). Supabase's custom OIDC option wants asymmetrically signed JWTs behind an OIDC discovery URL, so you would wire that up yourself, or skip the Data API and do authorization in your server code. Pick Better Auth when you want auth fully inside your codebase and plan to query the database from your server.

## Which should your SaaS use?

- **Your data is in Supabase and you want one backend:** Supabase Auth. Users, teams and policies sit in one database, and RLS needs no extra integration.
- **You need polished sign-in and team UI this week, and auth cost per user isn't a worry yet:** Clerk.
- **You want auth code you own, on any database:** Better Auth.

shipanysaas takes the first route. Sign-in runs on Supabase Auth with password, magic link, one-time codes, passkeys and OAuth, each switched on with an environment variable (see [Authentication](https://shipanysaas-demo.vercel.app/docs/authentication/authentication)). Teams, roles and invitations are Postgres tables behind row level security, covered in [Teams and invitations](https://shipanysaas-demo.vercel.app/docs/features/teams-and-invitations). Billing sits on top; [Polar vs Stripe vs Lemon Squeezy](https://shipanysaas-demo.vercel.app/blog/polar-vs-stripe-vs-lemon-squeezy) compares the payment side.

## FAQ

### Can I use Clerk with Supabase?

Yes. Add Clerk as a third-party auth provider in Supabase, add the `role` claim to Clerk's session tokens, and pass Clerk's token to the Supabase client through `accessToken()`. Policies then read `auth.jwt()->>'sub'`. Supabase bills these users as third-party MAUs above your plan's quota.

### Is Supabase Auth free?

Up to 50,000 monthly active users on the Free plan, and 100,000 on Pro, which starts at $25 a month. Phone MFA, SAML SSO and some security features cost extra or need Pro.

### Does Clerk support passkeys on the free plan?

No. As of October 2026, Clerk's pricing page lists passkeys, MFA and SMS codes on Pro and above, not on Hobby.

### Can I move from Clerk to Supabase Auth later?

Yes, but plan for it. You export users from Clerk, import them into Supabase Auth, change `text` user id columns to Supabase user ids, rewrite policies that read `sub`, and replace Clerk's components with your own pages.

### Is Better Auth better than Supabase Auth?

It depends on where you want auth to run. Better Auth is a free library that runs in your app. Supabase Auth is a managed service that works with RLS out of the box. If your app queries Supabase from the browser, Supabase Auth is the simpler fit.