· auth / clerk / supabase

Clerk vs Supabase Auth 2026: Pick One Before 50K Users

Clerk ships auth UI in minutes; Supabase costs 41× less at 100K MAU. The crossover is exactly 50,001 active users — and that number should drive your decision.

By Ethan

2,297 words · 12 min read

Both start at $25/month. At 100,000 monthly active users, Clerk costs $1,025 and Supabase costs $25 — a 41× gap. Below 50,000 users, the price is identical and Clerk’s zero-config middleware and pre-built UI components save you hours.

Pick Clerk if you need a polished sign-in UI, enterprise SSO, or machine auth with no plumbing. Pick Supabase if you’re on Postgres already, expect to grow past 50K users on a budget, or need to self-host your auth data.

Who this is for

Developers choosing an authentication layer for a Next.js app (App Router) in 2026 — comparing a dedicated hosted auth service against the auth module bundled into an open-source Postgres BaaS. If you’re on a non-Postgres stack, building for LDAP, or running entirely on Cloudflare Workers without a database, the comparison signal here is limited.

What we compared

Pricing data verified against official documentation on 2026-05-21:

  • Clerk: clerk.com/pricing, Core 3 release notes (March 2026), API Keys GA (April 2026)
  • Supabase: supabase.com/pricing, GitHub changelog, API key format migration docs

Code samples tested against Next.js 15.3 (App Router) on Node 22.

Feature comparison

FeatureClerkSupabase Auth
Setup time~15 minutes~30–45 minutes
Social logins20+ providers, zero configManual OAuth setup per provider
MFATOTP, SMS, backup codesTOTP, SMS
Enterprise SSO / SAMLPro tier, dashboard-configuredManual (third-party integration)
Machine auth (API keys)GA April 2026JWT-based, DIY
PasskeysYesYes
Self-hostingNoYes (Docker Compose)
Open sourceNoYes (Apache 2.0)
Postgres-native sessionsNo (external store)Yes
Row Level Security integrationNoYes (auth.uid() in policies)
Free tier50,000 MRU50,000 MAU
Paid base$25/mo, 50K MRU$25/mo, 100K MAU

Both free tiers now include 50,000 active users — Clerk at 50K MRU, Supabase at 50K MAU. For side projects that stay below that threshold, neither service costs anything.

DX deep dive

Clerk: auth done for you

Clerk’s value proposition is time-to-ship. The Core 3 Next.js integration (March 2026) reduces route protection to a single middleware file:

// middleware.ts
import { clerkMiddleware } from '@clerk/nextjs/server'
export default clerkMiddleware()
export const config = {
  matcher: ['/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)', '/(api|trpc)(.*)', '/__clerk/(.*)'],
}

That file protects every route except static assets. No custom JWT validation, no session store queries, no cookie parsing. The middleware runs on the Edge Runtime — cold starts don’t apply.

The layout imports Core 3 components. Note: <SignedIn> and <SignedOut> are deprecated in Core 3. Use <Show>:

// app/layout.tsx
import { ClerkProvider, SignInButton, SignUpButton, Show, UserButton } from "@clerk/nextjs";

<Show when="signed-in"> and <Show when="signed-out"> replace the deprecated wrappers. The migration is a rename; existing rendering logic stays the same.

Beyond the middleware, Clerk ships complete sign-in and sign-up UI components. You don’t write auth forms. For a typical B2B SaaS app, that eliminates 40–60 lines of form code, the accessibility audit on those forms, and the mobile layout pass. The <UserButton /> component adds a profile dropdown — avatar, settings link, sign-out — in one import.

The April 2026 API Keys GA adds machine-to-machine authentication. External services, webhook consumers, and background workers authenticate using API key credentials created in the Clerk dashboard, distinct from user sessions. No additional infrastructure, no separate token service.

Clerk also ships an Organizations API for multi-tenant apps: create orgs, manage memberships, enforce roles at the middleware level. For a B2B product, this removes a week of data modeling.

Clerk’s organization management API is underrated for B2B. You get org creation, invitations, role-based access, and org-scoped JWT claims out of the box. In a multi-tenant SaaS product, building equivalent functionality yourself involves a teams table, an org_memberships join table, invitation tokens with expiry, email transactional flows, and role enforcement at every API route. Clerk ships all of it. Whether that’s worth the per-MAU cost depends entirely on how far you’d otherwise go to build it yourself.

The limitation is coupling. Clerk is a hosted service with no self-hosting path. Your users, sessions, and org data live on Clerk’s infrastructure. If Clerk has an outage, your auth is down. If Clerk changes its pricing model, you reprice too. Migrating off Clerk means exporting user data, rebuilding the sign-in UI, rewiring every JWT claim your app reads, and auditing every route that relied on Clerk’s organization claims. It’s a multi-sprint project. That’s not a reason to avoid Clerk — it’s a reason to make the decision consciously.

If your main concern is avoiding per-MAU costs and vendor lock-in, Auth.js vs Clerk compares Clerk against the open-source DIY path in detail.

Supabase: auth as a Postgres layer

Supabase Auth is GoTrue — an open-source auth service — running against your Postgres database. Users, sessions, and tokens are rows in your own schema. Your auth data and application data share a transaction boundary.

The Next.js quickstart:

npx create-next-app -e with-supabase

That template wires up the SSR client with cookie-based session persistence for the App Router. A server component session check:

// app/page.tsx (server component)
import { createClient } from '@/utils/supabase/server'
const supabase = await createClient()
const { data: { user } } = await supabase.auth.getUser()

createClient() is async in the template — it reads cookies via the Next.js cookies() API. The user object comes from your own Postgres instance, not a third-party API.

The Postgres-native design unlocks Row Level Security. A policy like:

CREATE POLICY "Users see own posts" ON posts
  FOR SELECT USING (auth.uid() = user_id);

means the database itself enforces authorization. auth.uid() returns the authenticated user’s UUID from the session token. You don’t write authorization logic in your application — the DB rejects unauthorized reads at the query level.

What you give up: you build your own UI. The with-supabase template ships an email/password form; social auth requires manual OAuth provider setup in the Supabase dashboard. Each provider takes 15–30 minutes to configure. MFA setup is similar. Budget a half-day for any social auth requirements beyond email/password.

If you’re deciding between Supabase and another full BaaS, Supabase vs Firebase covers that comparison in full.

Notable 2025–2026 Supabase change worth tracking:

  • New API key format: sb_publishable_xxx / sb_secret_xxx replaces the old anon / service_role convention. Existing keys still work; new projects get the new format automatically.

Security model

Clerk’s security model is trust-the-vendor. Clerk manages signing keys, rotates secrets, and handles session revocation. You don’t control these directly. The tradeoff is simplicity: you never misconfigure a JWT secret, but you also can’t audit what happens to your session data at rest on Clerk’s systems. Clerk is SOC 2 Type II certified; for most apps that’s sufficient.

Supabase’s security model is: it’s your Postgres database, you own the keys. JWT signing secrets live in your own infrastructure. You configure Postgres SSL settings, network access rules, and backup encryption yourself. Row Level Security policies are code you write and audit. The attack surface you control is larger — which means more responsibility, not inherently more risk.

The practical difference shows up in compliance conversations. “We’re SOC 2 certified and use Clerk, a SOC 2 certified vendor” is a sentence that closes many enterprise security reviews. “We self-host Supabase and own the full security posture” either accelerates or stalls the same review depending on your customer’s security team. Know your customer before you pick.

Pricing crossover

Both products are $25/month on Pro. The difference is what’s included and what it costs when you exceed the allowance.

Clerk Pro: $25/month, 50,000 MRU included. Overage: $0.02/MRU for 50K–100K, $0.018/MRU for 100K–1M.

Supabase Pro: $25/month, 100,000 MAU included. Overage: $0.00325/MAU.

MAUClerk (monthly)Supabase (monthly)Difference
10,000$0 (free tier)$0 (free tier)—
50,000$25$25$0
50,001~$25.02$25.00Supabase cheaper
75,000$525$25$500
100,000$1,025$25$1,000
200,000$2,825$350$2,475
500,000$8,225$1,325$6,900
1,000,000$17,225$2,950$14,275

At 100K MAU, Clerk costs 41× more. At 1M MAU, the delta is $14,275/month — $171,300/year. That’s a senior engineer’s salary in many markets, spent entirely on auth infrastructure.

Three important caveats before optimizing for the 1M-user row:

1. MRU ≠ MAU exactly. Clerk bills in Monthly Rate Units. For most consumer apps, MRU ≈ MAU. Enterprise SSO customers may count differently — a user who authenticates twice via different SSO connections could count as two MRUs. Check Clerk’s billing FAQ for your specific setup before projecting costs.

2. Supabase has additional compute charges. The $25/month base includes the auth service but not all the compute, storage, and egress for a production-scale deployment. At 1M MAU you’ll have meaningful Supabase compute add-ons on top of the auth-only number. The gap in the table above is real but somewhat narrower when you add infrastructure overhead.

3. Self-hosting Supabase is free. Docker Compose, no per-MAU charge. At very high scale, the total cost of ownership — server costs plus DevOps time to run Postgres, GoTrue, and backups — may approach Clerk’s fees depending on your team structure. Self-hosting Supabase at 1M MAU is a real option; it requires meaningful operational ownership that a two-person team may not have capacity for.

Ecosystem fit

Vercel

Both work on Vercel. Clerk is slightly better tuned for it: @clerk/nextjs middleware runs natively on the Edge Runtime, no configuration required. Supabase’s @supabase/ssr package also targets the Edge, but the createClient() helper in the with-supabase template uses Node.js cookie APIs. If you need Supabase auth on Vercel Edge Functions specifically, test it against @supabase/ssr directly rather than the template helper.

For Vercel Functions (Node runtime), both work without caveats. Clerk’s Vercel integration also auto-sets environment variables when you connect the project in the Clerk dashboard — one fewer manual step compared to copying Supabase keys by hand.

Cloudflare Workers

Clerk supports Cloudflare Workers via @clerk/backend. You need Node.js compatibility mode (nodejs_compat flag in wrangler.toml). Supabase supports Workers via @supabase/supabase-js natively — the client uses the Fetch API, no Node compatibility flag required.

For Workers-only deployments without a Postgres database, Supabase’s main architectural advantage — co-located auth and data — disappears. You’d be using Supabase Auth as a hosted service with no RLS benefit. In that case, Clerk’s zero-config middleware is the better fit.

Docker / VPS / self-hosted

Clerk doesn’t self-host. This is a hard constraint, not a roadmap item. If your deployment policy requires auth data to stay inside your perimeter — healthcare (HIPAA), regulated finance (SOC 2 Type II with data residency requirements), government, or air-gapped infrastructure — Clerk is off the table.

Supabase self-hosts via the official docker-compose.yml. Running docker compose up starts Postgres, GoTrue (the auth service), PostgREST, Storage, and Realtime. Auth sessions, user records, and JWT secrets stay on your hardware. The setup takes an hour; ongoing maintenance is a real cost, but the control is real too.

Final recommendation

ProfilePickReason
Solo dev, side projectSupabasePostgres-native, self-hostable, RLS integration
Small team, B2C product, < 50K usersClerkPre-built UI ships faster
Growth stage, 50K–500K usersSupabase$500–$6,900/mo cost advantage
Enterprise SaaS, SAML requiredClerkSSO is dashboard-configured, not DIY
OSS project / self-hostedSupabaseClerk offers no self-hosting option
Existing Supabase projectSupabase AuthTwo session stores and two bills add complexity

The core question is: do you want a vendor to own your auth infrastructure, or do you want to own it yourself?

Clerk is the right answer when auth needs to ship today, when your team has limited bandwidth for OAuth configuration, or when enterprise SSO is a sales blocker you can’t afford to delay. The convenience has a real price — the crossover is 50,001 MAU, and the gap widens fast.

Supabase is the right answer when you’re already on Postgres, when the pricing curve matters at your target scale, or when self-hosting is non-negotiable. The setup cost is one afternoon per developer. The long-term cost is substantially lower.

If you’re building a B2B SaaS that expects to grow, and you’re not on Vercel Edge with Workers-only constraints, start with Supabase. The RLS integration alone eliminates a category of authorization bugs that Clerk doesn’t address — authorization logic that lives in the database can’t be accidentally bypassed by a missing middleware call. If you later need Clerk’s Organization API or enterprise SSO, migration is a substantial project, not a weekend fix. Build the multi-tenant data model in Postgres from day one and avoid that migration entirely.

If you’re building a consumer app and want sign-in done by lunch, start with Clerk. The UI components, social auth, and passkeys are production-quality on day one. Revisit pricing at 40K MAU — you have a decision window before the cost curve bends sharply.

If you’re in the 40K–50K range right now, don’t wait until you cross the threshold. Migrating auth providers under load is unpleasant. Run the pricing math at your projected 12-month MAU and make the decision with time to spare.

References