Better Auth vs Clerk vs NextAuth vs Supabase Auth: Which Authentication for Next.js SaaS in 2026

For a new Next.js SaaS in 2026, the right authentication pick is almost always Better Auth or Supabase Auth. Better Auth if you want a TypeScript-native library that owns your users in your own Postgres with first-class multi-tenancy. Supabase Auth if you are already on Supabase and want Row Level Security to do half your authorization work for you. Clerk and NextAuth (Auth.js v5) are the other names you will hear, but they solve narrower problems: Clerk is a hosted convenience that gets expensive past 50,000 MAU and locks your user data in a US database, and NextAuth is a legacy library most teams keep only because they already use it.

This guide compares the four options developers actually evaluate in 2026 — Better Auth, Supabase Auth, Clerk, and NextAuth — but we are not going to pretend the field is even.

We ship both Better Auth kits with Drizzle or Prisma, and Supabase Auth kits in MakerKit because those are the two options we would actually use to build a product.

The other two are covered here so you can run the math yourself, as they're also very popular.

Quick Decision Matrix

We have ordered the columns by what we would actually recommend: Better Auth and Supabase Auth first, the other two after.

After shipping both the Better Auth kits and the Supabase Auth kits at MakerKit, the pattern we see is consistent: the teams that ship and stay on their original auth pick almost always chose Better Auth or Supabase Auth. The teams that migrate at month nine almost always started on Clerk. Knowing this in advance lets you skip the migration entirely.

If you also need to pick a database layer, the companion guide on Drizzle vs Prisma covers the ORM choice that pairs with this decision.

The Four Options in 2026

Before going deep on each, a one-paragraph orientation. The four options solve overlapping problems with very different opinions.

• Better Auth is a TypeScript-first auth library that runs inside your Next.js app and writes to your database. You control the schema, the cookies, and the deployment. This is the option we recommend for new multi-tenant SaaS that are not already on Supabase.
• Supabase Auth ships as part of Supabase and integrates natively with Postgres Row Level Security. If you are already on Supabase, this is the option we recommend; the RLS integration alone replaces a meaningful chunk of authorization code you would otherwise write by hand.
• Clerk is a hosted authentication service. You add their SDK, get production-quality sign-in screens and user management out of the box, and pay per monthly active user. It is the fastest path to a working sign-in form and the slowest to scale a cost-controlled business on top of.
• NextAuth, now officially called Auth.js v5, is the original Next.js auth library. Same package (next-auth), same maintainers, new docs site. It is OAuth-focused with adapters for major databases and is mostly relevant today for apps that already run on it.

What Is Better Auth?

Better Auth is a TypeScript authentication library for full-stack frameworks that runs in your app and stores users in your database. It launched in 2024 and reached v1.6 in May 2026. Unlike hosted providers, there is no external service to call. The auth code lives in your codebase, the sessions live in your Postgres, and you deploy it the same way you deploy anything else.

Better Auth covers the standard surface: email and password, social providers, magic links, passkeys, two-factor authentication, and rate limiting. The features that matter most for SaaS are bundled as plugins: organizations, teams, role-based access control, and admin tooling.

A working setup with Drizzle and Postgres looks like this:

// auth.ts
import { betterAuth } from 'better-auth';
import { drizzleAdapter } from '@better-auth/drizzle-adapter';
import { organization } from 'better-auth/plugins';
import { db } from './database';
export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: 'pg',
  }),
  emailAndPassword: {
    enabled: true,
  },
  socialProviders: {
    github: {
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    },
  },
  plugins: [organization()],
});

Generate the schema once with npx auth@latest generate, run the migration, and you have working auth with organizations included. The CLI is the part most newcomers miss; it produces the user, session, account, verification, organization, member, and invitation tables for you.

The client side is similarly compact:

// auth-client.ts
import { createAuthClient } from 'better-auth/client';
import { organizationClient } from 'better-auth/client/plugins';
export const authClient = createAuthClient({
  plugins: [organizationClient()],
});
// In a component
await authClient.signIn.email({
  email: 'user@example.com',
  password: 'correct-horse-battery-staple',
});

The opinionated take after shipping this in production: Better Auth is what NextAuth would look like if it were redesigned for the App Router era from a clean sheet.

What Is Clerk?

Clerk is a hosted authentication and user management platform. You add their SDK, drop in their <SignIn /> component, and get a complete auth experience including profile pages, MFA prompts, organization switchers, and a polished dashboard for your team. The user data lives in Clerk's infrastructure in the US.

The minimum integration in a Next.js 16 App Router app:

// middleware.ts
import { clerkMiddleware, createRouteMatcher } from '@clerk/nextjs/server';
const isProtectedRoute = createRouteMatcher(['/dashboard(.*)']);
export default clerkMiddleware(async (auth, req) => {
  if (isProtectedRoute(req)) {
    await auth.protect();
  }
});
export const config = {
  matcher: ['/((?!_next|[^?]*\\.(?:html?|css|js)).*)', '/(api|trpc)(.*)'],
};

And the actual sign-in page:

// app/sign-in/[[...sign-in]]/page.tsx
import { SignIn } from '@clerk/nextjs';
export default function Page() {
  return <SignIn />;
}

Three files, one polished sign-in flow. This is the reason Clerk wins the "I need auth in 20 minutes" segment, and it is genuinely useful — for the first nine months. After that, the tradeoffs are the bill, the lock-in, and the fact that your user table is in a US database you do not control.

Clerk overhauled its pricing in February 2026. The free tier moved from 10,000 to 50,000 monthly active users, which materially changes the calculus for early-stage SaaS. The Pro plan starts at $25/mo and adds $0.02 per MAU above 50,000. The free-tier expansion delays the migration conversation by about six months; it does not eliminate it. We will look at the cost curve next.

What Is NextAuth (Auth.js v5)?

NextAuth is the original Next.js authentication library, now branded as Auth.js v5. The package is still next-auth, the maintainers are the same, but the docs and ecosystem refer to it as Auth.js. If you have read articles calling these "two different libraries", they are not. Auth.js is the rebranded NextAuth.

The library is OAuth-focused and works with any framework that supports edge runtimes. v5 (which has been in beta since 2024 and stable in 2025) brought a much cleaner config and split server/client APIs:

// auth.ts
import NextAuth from 'next-auth';
import GitHub from 'next-auth/providers/github';
import { DrizzleAdapter } from '@auth/drizzle-adapter';
import { db } from './database';
export const { handlers, auth, signIn, signOut } = NextAuth({
  adapter: DrizzleAdapter(db),
  providers: [GitHub],
});

NextAuth still owns the largest installed base in the Next.js auth space, mostly because it was the default recommendation for years. Migration to Better Auth has accelerated through 2026, especially among teams that need first-class support for organizations, passkeys, and RBAC without writing it themselves. For new projects, NextAuth is rarely the right pick anymore: Better Auth gives you more out of the box, Supabase Auth integrates more tightly with your database, and Clerk ships UI.

If you have an existing NextAuth setup that works, there is no urgent reason to rip it out. If you are starting fresh, we would not start a new project on NextAuth in 2026.

What Is Supabase Auth?

Supabase Auth is the bundled authentication layer of the Supabase platform and one of the two options we recommend for new projects in 2026. It is built on the open-source GoTrue service and integrates directly with Postgres Row Level Security. If your app is already on Supabase, you can use it without adding another dependency, and the integration with the database does real work for you that no other option matches.

// supabase-client.ts
import { createClient } from '@supabase/supabase-js';
export const supabase = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
);
// Sign in
await supabase.auth.signInWithPassword({
  email: 'user@example.com',
  password: 'correct-horse-battery-staple',
});

Supabase Auth covers email, OAuth, magic links, SMS, MFA, anonymous sign-in, and SSO (paid). It also handles email deliverability, password reset flows, and JWT refresh out of the box — three things you would build yourself with a self-hosted library.

The killer feature is the tight RLS integration: auth.uid() is available in every Postgres policy, which makes multi-tenant access control enforceable at the database layer. This is not a small thing. With Better Auth or NextAuth you write authorization in application code; with Supabase Auth you write it once in SQL and every query — from your Next.js server actions, your API routes, your background jobs, even a direct SQL client — is automatically scoped to the signed-in user. Bugs in application code cannot leak data across tenants, because the database itself refuses the query.

This is why every Supabase-based MakerKit kit uses Supabase Auth. The combination of identity, RLS, and Postgres in one platform replaces three components you would otherwise wire together. The MakerKit Supabase kits ship a complete account model — personal accounts, team accounts, members, roles, invitations, and permission boundaries — built on top of Supabase Auth and enforced through RLS policies.

If you are all-in on Supabase, this is the path of least resistance and the path we would choose. If you are using Supabase only as a Postgres host (which is increasingly common), you can run Better Auth on top of the same Supabase Postgres database, which we will cover below.

Cost at Scale: Real Numbers

The cost curve is where this comparison gets practical. Here is what each option roughly costs at three common SaaS scales, using the published 2026 pricing.

A few notes on the Clerk number at 100,000 MAU. The base is $25/mo (Pro) and the marginal cost above 50,000 MAU is $0.02 per MAU per month. 50,000 extra users times $0.02 is $1,000. The total is roughly $1,025/mo. That is one engineer-day of cost every month for the auth layer alone.

The Supabase number assumes you are already paying for Supabase regardless of auth choice; if you are, auth is effectively free.

The Better Auth and NextAuth numbers assume a modest Postgres database. If you scale Postgres for other reasons (analytics, search), auth's marginal cost stays near zero because user, session, and account rows are cheap.

The common migration pattern in 2026 is: ship on Clerk to get to product-market fit, then move to Better Auth or Supabase Auth somewhere around the 50K-MAU mark when the bill starts catching engineering attention.

Multi-Tenant SaaS: Where Better Auth Wins

This is the section that competitor comparisons skip. Most auth posts cover "log in with Google" and stop there. Real SaaS apps have teams, workspaces, organizations, roles, invitations, and permission boundaries. The library you pick decides whether multi-tenancy is a plugin or a side quest.

Better Auth's organization plugin generates the schema and APIs for you:

// auth.ts
import { betterAuth } from 'better-auth';
import { drizzleAdapter } from '@better-auth/drizzle-adapter';
import { organization } from 'better-auth/plugins';
import { db } from './database';
export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: 'pg' }),
  plugins: [
    organization({
      allowUserToCreateOrganization: true,
      organizationLimit: 5,
    }),
  ],
});

After npx auth@latest generate you get four new tables: organization, member, invitation, and an extended session with activeOrganizationId. The plugin ships with three default roles (owner, admin, member) out of the box; you can define additional roles if you need them. The Drizzle schema looks like this:

// schema.ts (excerpt, auto-generated)
import { pgTable, text, timestamp } from 'drizzle-orm/pg-core';
export const organization = pgTable('organization', {
  id: text('id').primaryKey(),
  name: text('name').notNull(),
  slug: text('slug').unique().notNull(),
  logo: text('logo'),
  metadata: text('metadata'),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});
export const member = pgTable('member', {
  id: text('id').primaryKey(),
  organizationId: text('organization_id')
    .notNull()
    .references(() => organization.id, { onDelete: 'cascade' }),
  userId: text('user_id')
    .notNull()
    .references(() => user.id, { onDelete: 'cascade' }),
  role: text('role').notNull(),
  createdAt: timestamp('created_at').defaultNow().notNull(),
});

Client usage is one line per operation:

// Create a workspace
await authClient.organization.create({
  name: 'Acme Corp',
  slug: 'acme',
});
// Invite a member
await authClient.organization.inviteMember({
  email: 'teammate@acme.com',
  role: 'admin',
});
// Switch active organization
await authClient.organization.setActive({ organizationId });

By comparison, Clerk offers Organizations as a paid feature with similar primitives but the data lives in Clerk's database, not yours. NextAuth has nothing native. Supabase Auth provides identity and auth.uid() for RLS but leaves the team/workspace model to you — which is exactly what the MakerKit Supabase kits provide, with personal accounts, team accounts, member tables, roles, and invitations modeled in your own schema and enforced through RLS. The point: on Supabase you build the org model once and the database enforces it on every query; on Clerk and NextAuth you build it and hope every code path remembers to call the right helper.

If your product is multi-tenant from day one and you are not already on Supabase, this is the single biggest reason to pick Better Auth. If you are on Supabase, the MakerKit Supabase kits give you the same primitives on top of Supabase Auth + RLS.

Better Auth + Supabase: Do I Need Both?

A question we get every week: "I am using Supabase for Postgres. Do I need Supabase Auth, or can I run Better Auth?"

You can run Better Auth on top of Supabase Postgres. Better Auth does not care whether your Postgres comes from Supabase, Neon, Railway, or a self-hosted instance. It just needs a connection string.

// database.ts
import { drizzle } from 'drizzle-orm/postgres-js';
import postgres from 'postgres';
const client = postgres(process.env.DATABASE_URL!);
export const db = drizzle(client);

// auth.ts
import { betterAuth } from 'better-auth';
import { drizzleAdapter } from '@better-auth/drizzle-adapter';
import { db } from './database';
export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: 'pg' }),
});

When to use Better Auth on Supabase Postgres:

• You want the organization plugin, passkeys, and RBAC without writing them.
• You want your auth state in your own tables (not in auth.users).
• You want to migrate off Supabase one day without rewriting auth.

When to stick with Supabase Auth:

• You rely heavily on RLS policies using auth.uid().
• You use Supabase magic links, OAuth, or SMS and the integration just works.
• You want one less moving part.

Both options can coexist if you really want them to, but in practice teams pick one. For a side-by-side of the underlying database trade-offs, the Supabase vs the rest of the BaaS market comparison covers the data layer.

Self-Hosted vs Hosted: The Real Tradeoffs

Self-hosting (Better Auth, NextAuth) means you own the operational surface. Hosted (Clerk) means you outsource it. Neither is universally better. Here is what you actually take on in each direction.

What you take on with self-hosted auth:

• Database backups for user data.
• Email deliverability for password resets and verifications.
• Rate limiting and brute-force protection (Better Auth ships rate limiting; you still need an IP-aware edge layer in front).
• Session storage scaling (typically not a problem until very high scale).
• Security patches and breach response.

What you take on with hosted auth:

• Vendor pricing changes (Clerk has changed pricing twice in three years).
• Data residency limits (Clerk is US-only as of 2026, which is a real GDPR concern for EU businesses).
• Account lock-in. If Clerk goes down, your users cannot sign in.
• Compliance lifts. Their SOC2 is theirs, not yours, but it can be referenced.

A common heuristic: if you are a one-person team shipping a B2C app, hosted auth removes more pain than it creates. If you are a B2B SaaS that will sell to enterprise customers who ask "where is our data stored", self-hosted auth gives you a cleaner answer.

Migration: Clerk to Better Auth in Practice

The most common migration in 2026 is Clerk to Better Auth at the 50K-MAU mark. Here is what it actually involves.

1. Schema and user export. Clerk lets you export users via their backend API. Better Auth ships a Clerk migration guide that maps Clerk's fields onto Better Auth's user and account tables. Plan for a one-time bulk insert.

2. Session shape change. Clerk's auth() returns userId. Better Auth's auth.api.getSession() returns a full session plus user object. Every component that reads the current user needs an update. This is the part that takes the most calendar time, mostly because it is mechanical and tedious.

3. Email and password re-issue. Clerk and Better Auth use different password hashing algorithms by default, so existing password hashes are not portable. You can either re-hash on first login (recommended, transparent to users) or trigger a password reset for every user (cleaner cutover, more support load).

4. Pre-built UI replacement. Clerk's <SignIn /> is replaced by your own form. Two days of work, maybe three if you want it polished. The first MakerKit kit migrated this in an afternoon by lifting the sign-in form from our reference codebase.

5. Webhooks and integrations. Any service that listens to Clerk's user.created webhook needs to switch to Better Auth's user lifecycle hooks. Catch this early; it is easy to forget when Stripe customer creation or analytics events depend on it.

For a typical mid-sized app (10–50K users, a few OAuth providers, organizations), budget two engineer-weeks. Public migration writeups (the Val Town blog post on auth migration is one) cover the rough edges end to end.

What We Chose for MakerKit (and Why)

We ship two auth defaults at MakerKit, one for each stack: Better Auth in the Drizzle and Prisma kits, and Supabase Auth in the Supabase kits. We did not ship a Clerk kit or a NextAuth kit because we would not start a new SaaS on either.

The shared reasoning behind both picks:

Cost predictability. A SaaS that grows from 1,000 to 100,000 users should not see its auth bill grow from $0 to $1,000/mo. Better Auth's cost is your Postgres bill; Supabase Auth is included in the Supabase plan you are already paying for.

Multi-tenancy as a first-class concern. Every MakerKit kit ships with workspaces, members, roles, invites, and permission boundaries. Better Auth's organization plugin gives us this on the library side. On the Supabase side, we model the same primitives in our own schema and enforce them with RLS — which is arguably more powerful, because the database itself refuses cross-tenant queries instead of trusting application code to remember.

Data ownership. Our customers ship to EU users, regulated industries, and enterprise prospects. "Where is your auth data?" has a clean answer when the user table is a row in their own Postgres — whether that Postgres is hosted by Supabase, Neon, or self-hosted.

Stack-fit beats one-size-fits-all. Better Auth has first-class adapters for Drizzle and Prisma; Supabase Auth has first-class integration with Postgres RLS. Picking based on which database story you want is a real choice. Picking based on which hosted provider has the prettiest sign-in component is not.

Honest tradeoffs we tell customers directly:

• Better Auth does not yet have native SAML or SCIM. The SAML plugin is in active development. Until it ships, teams that need SAML/SCIM bolt on WorkOS or a similar service for the SSO layer while keeping Better Auth for everything else.
• Supabase Auth ties you to Postgres (no real downside in our view) and the team/workspace model is on you to build — which the MakerKit Supabase kits already do.

When customers ask which kit to pick: if you want the auth library you can lift-and-shift to any Postgres, choose a Better Auth kit. If you want database-enforced authorization and the rest of Supabase (storage, realtime, edge functions) in one platform, choose a Supabase kit. Both are good answers. Clerk and NextAuth are not currently on the list.

For more on how the kits are structured, see the announcement post or the documentation for Better Auth in the Drizzle kit.

Common Pitfalls to Avoid

Some footguns we have either hit ourselves or seen customers hit.

1. Picking Clerk knowing you cannot afford it at scale. If your business plan has you at 200,000 MAU in 18 months, you are signing up for a $4,000/mo bill that you will need to migrate away from. Run the math on day one.
2. Treating NextAuth and Auth.js as different libraries. They are the same package (next-auth). The docs site is authjs.dev. Half the comparison articles online conflate or separate them inconsistently; trust the package name in your package.json.
3. Mixing Supabase Auth and a separate auth library on the same Postgres. This is possible but creates two sources of truth for "who is the user". Pick one and stick with it.
4. Forgetting to migrate webhooks during a Clerk swap. The user.created webhook is the single most-integrated event in many apps (Stripe customer creation, analytics, etc.). Map every listener before the cutover.
5. Skipping the rate limiter. Better Auth ships rate limiting, but the default uses an in-memory store that resets on every deploy. For production, configure Redis or your edge provider.
6. Storing organization data outside the auth schema. Better Auth's organization plugin generates a member table with roles. Resist the temptation to build your own team_members table next to it; you will end up with two membership models.
7. Relying on Clerk for EU data residency without reading the fine print. Clerk stores user data in the US under the EU-US Data Privacy Framework. If your customers ask for data residency in a specific EU country, you cannot deliver it on Clerk today.

Mobile and Edge: A Quick Note

Two cases worth mentioning briefly.

If you ship a React Native or Expo app alongside your web app, Better Auth has an Expo plugin that handles the deep-link OAuth flow and secure storage. The integration is one of the reasons we ship Better Auth in the MakerKit Expo kit: the same auth instance powers web and mobile.

If you deploy on Cloudflare Workers or Vercel Edge, all four options work, but the operational details differ. Better Auth needs an edge-compatible Postgres driver (Neon's serverless driver or Supabase's pooler). Clerk works out of the box because it is just HTTP. NextAuth supports edge runtime as of v5. Supabase Auth depends on which client you use.

Quick Recommendation

Better Auth (recommended) is best for:

• Multi-tenant SaaS that ships with workspaces, roles, and invitations from day one.
• Teams that want predictable auth cost as they scale past 50,000 users.
• Apps where data residency or self-hosting is a hard requirement.
• Stacks built on Drizzle or Prisma without Supabase.

Supabase Auth (recommended) is best for:

• Anything built on Supabase. The RLS integration is the strongest data-protection story of the four options.
• Multi-tenant SaaS that want database-enforced authorization, not application-enforced.
• Teams that want identity, storage, realtime, and Postgres in one platform.

Clerk is best for:

• Solo developers, hackathons, weekend prototypes.
• B2C apps where speed-to-launch matters more than long-term cost.
• Products that will stay comfortably under 50,000 MAU for the foreseeable future, with no EU data residency requirement.

NextAuth (Auth.js v5) is best for:

• Existing apps already on NextAuth that work fine.
• OAuth-only apps where you do not need orgs, RBAC, or passkeys — and you have a specific reason not to pick Better Auth.

Our pick: Better Auth if you are not on Supabase. Supabase Auth if you are. We would not start a new SaaS on Clerk or NextAuth in 2026.

So, Which One Should You Pick?

If you are already on Supabase, pick Supabase Auth — the RLS integration alone justifies the choice, and the MakerKit Supabase kits give you the team/workspace model on top. If you are not on Supabase and you are building multi-tenant from day one, pick Better Auth. Both options age well, both keep your users in your own database, and both let you walk away from a vendor without rewriting auth. Clerk is a fine prototyping tool but a thin foundation for a business; NextAuth is a fine maintenance load for an existing app but rarely the right pick for a new one. The only wrong choice is picking on vibes without running the cost math at your target scale.

Next Steps

If you want a working starting point for either of our two recommended options, the MakerKit kits ship them production-grade: Drizzle + Better Auth, Prisma + Better Auth, and the Supabase kits with Supabase Auth and RLS-enforced multi-tenancy. For the database layer that pairs with this decision, see the Drizzle vs Prisma comparison.

Tested with Next.js 16.x, React 19, Better Auth 1.6, Drizzle 0.x, and Supabase 2.x as of May 2026.