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.

Updated October 2026: covers Better Auth 1.7 (including its SSO and SCIM plugins) and Clerk's current MRU-based pricing.

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.

MakerKit ships Better Auth and Supabase Auth because those are the two options we would actually use to build a product. The full production wiring for one of them is documented in Better Auth on TanStack Start.

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. The package is still next-auth. Since September 2025 the Better Auth team maintains it, and their own recommendation is to start new projects on Better Auth. 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, shipped v1.7 in August 2026, and the current release is 1.7.7. 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, admin tooling, and, for enterprise customers, SSO (SAML and OIDC) and SCIM provisioning. Some plugins now live in their own packages (@better-auth/passkey, @better-auth/sso, @better-auth/scim, @better-auth/stripe), so you install only what you use.

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 give you a polished sign-in flow. That's why Clerk wins the "I need auth in 20 minutes" segment, and the value is real for the first nine months. After that, three costs grow: the monthly bill, the work required to migrate away, 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 users per app, which materially changes the calculus for early-stage SaaS. Clerk bills on Monthly Retained Users (MRUs) rather than raw monthly active users: a user counts once they come back to your app after signing up. The Pro plan costs $25/mo ($20/mo billed annually) and adds $0.02 per MRU from 50,001 to 100,000, with lower rates at higher volumes. Basic Organizations (up to 100 organizations and 20 members each) are now free on every plan; custom roles, verified domains, and unlimited members need the $100/mo Enhanced B2B Authentication add-on. 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, 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.

On September 22, 2025, Auth.js became part of Better Auth. The Better Auth team now maintains it and ships security patches and critical bug fixes, so existing apps can keep running it. For new projects, the announcement recommends Better Auth unless you need a feature only Auth.js has, most notably stateless sessions without a database.

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. Those are three things you would build yourself with a self-hosted library.

Its most important feature is the 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.

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.

Better Auth vs Clerk vs the Rest: Cost at Scale

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, billed monthly) and the marginal cost from 50,001 to 100,000 users is $0.02 per MRU per month. 50,000 extra users times $0.02 is $1,000. The total is roughly $1,025/mo. Because Clerk counts retained users rather than every sign-up, your billed number can be lower than your raw MAU, but for a SaaS with returning customers the two are close. 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 Clerk's bill passes $1,000/mo.

Multi-Tenant SaaS: Where Better Auth Wins

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 you install multi-tenancy as a plugin or build it yourself. The auth library handles identity and orgs; the isolation underneath is a database problem, which we cover in multi-tenant SaaS architecture with Postgres RLS.

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 with similar primitives (free up to 100 organizations and 20 members each, with custom roles behind the $100/mo B2B add-on), 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. The MakerKit Supabase kits provide that model: personal accounts, team accounts, member tables, roles, and invitations in your own schema, enforced through RLS. The difference: 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.

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 Firebase 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 (on both Next.js and TanStack Start), 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 Better Auth kits run Better Auth 1.7 with these plugins configured: organization (workspaces, members, invitations, roles), admin, two-factor authentication, passkeys, magic link, email OTP, one-time token, last-login-method, captcha, and a billing plugin for Stripe or Polar. Magic link, passkeys, and captcha are toggled by configuration, and when one is off its endpoints are not registered at all. The Better Auth SaaS starter kit page has the full feature list.

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. That's 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 your database story is a real architectural choice. Picking based on which hosted provider has the best pre-built sign-in UI saves a few days now and often leads to a migration later.

Honest tradeoffs we tell customers directly:

• Better Auth has first-party SSO (SAML and OIDC) and SCIM plugins, reworked in v1.7, but they are not enabled in the kits by default. If you sell to enterprise customers, you add them yourself and run the schema migration. The 1.7 releases also changed how SSO account identities are stored, so read the upgrade guide before enabling SSO on an existing app.
• Supabase Auth ties you to Postgres (no real downside in our view).

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, the Better Auth SaaS starter kit overview, 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 Clerk Pro bill of roughly $2,800/mo (before any B2B or SSO add-ons) 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 and is not shared across serverless instances. For production, use database or secondary storage (Redis). The MakerKit Better Auth kits default to database storage for this reason.
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 (@better-auth/expo) that handles the deep-link OAuth flow and secure storage, so the same auth instance can power web and mobile. The MakerKit React Native kit is built on Supabase and uses Supabase Auth, which pairs with the Supabase web kits in the same way.

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 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. If you are not on Supabase and you are building multi-tenant from day one, pick Better Auth. Both keep your users in your own database, and both let you leave a vendor without rewriting auth. Clerk works for prototypes, but its cost and US-only data storage become problems as a business grows. NextAuth is reasonable to keep in an existing app, but its own maintainers recommend Better Auth for new projects. Whichever you choose, calculate the auth cost at your target user count before you commit.

Next Steps

If you want a working starting point for either of our two recommended options, the MakerKit kits ship them production-grade: the Better Auth kits (Drizzle or Prisma, on Next.js or TanStack Start), 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.4, React 19, Better Auth 1.7.7, Drizzle 0.45, Prisma 7, and Supabase 2.x as of October 2026.