Better Auth vs Clerk: why we chose Better Auth

Better Auth vs Clerk comes down to one question: where do your users and sessions live? Clerk keeps them in its hosted service. Better Auth writes them into your own database, as plain tables next to the rest of your app.

We moved from NextAuth to Better Auth in every new app and never picked Clerk. Honest limit first: we have not run Clerk in production. So this is not a benchmark. It is why we did not choose it, with the configs we actually run.

What is the difference between Better Auth and Clerk?

Better Auth is a library. It describes itself as "a framework-agnostic, universal authentication and authorization framework for TypeScript" (Better Auth docs, as of 2026-10-24). It is MIT licensed. Clerk is a hosted service with prebuilt sign-in components and a user dashboard.

The rows that decided it for us are the second and the third. Our clients own their code, data and infrastructure from day one. A user table on someone else's servers, billed per user, does not fit that.

Why did we move from NextAuth to Better Auth?

Our older client apps run NextAuth v4 with the Prisma adapter. They still run, and we leave them alone. Auth that works is not something we rewrite for a blog post.

For new apps the decision got easier in September 2025. Auth.js, the project formerly called NextAuth.js, moved under the Better Auth team. Their announcement says it plainly:

The gap they name is stateless sessions without a database. We want the database anyway, so it never applied to us.

What does Better Auth look like in a real app?

This is the auth package from our starter template, slightly shortened. TanStack Start on Cloudflare Workers, Drizzle on D1:

import { betterAuth } from 'better-auth'
import { drizzleAdapter } from 'better-auth/adapters/drizzle'
import { tanstackStartCookies } from 'better-auth/tanstack-start'
import { checkout, polar, portal } from '@polar-sh/better-auth'

export function createAuth() {
  const db = createDb()
  const plugins = [tanstackStartCookies()]

  // Billing only when the app has a payments token.
  if (env.POLAR_ACCESS_TOKEN) {
    plugins.push(polar({ client: polarClient, createCustomerOnSignUp: true, use: [checkout({ /* products */ }), portal()] }))
  }

  return betterAuth({
    database: drizzleAdapter(db, { provider: 'sqlite', schema }),
    trustedOrigins: [env.CORS_ORIGIN],
    emailAndPassword: { enabled: true },
    socialProviders: { /* Google and GitHub, only when their keys are set */ },
    secret: env.BETTER_AUTH_SECRET,
    baseURL: env.BETTER_AUTH_URL,
    plugins,
  })
}

The schema is ours too. Users and sessions are Drizzle tables like any other:

const user = sqliteTable('user', {
  id: text('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email').notNull().unique(),
  emailVerified: integer('email_verified', { mode: 'boolean' }).default(false).notNull(),
})

const session = sqliteTable('session', {
  id: text('id').primaryKey(),
  token: text('token').notNull().unique(),
  expiresAt: integer('expires_at', { mode: 'timestamp_ms' }).notNull(),
  userId: text('user_id').notNull().references(() => user.id, { onDelete: 'cascade' }),
})

That is the practical difference. A record created by a user is a foreign key to user.id in the same database. A report of "who did what" is one SQL join, not a call to an external API plus a sync job.

How does auth become part of your own code?

Our internal cockpit app shows how far this goes. Only a short list of people may sign up, all through GitHub. No auth vendor setting does that. It is a few lines in a database hook:

return betterAuth({
  database: drizzleAdapter(db, { provider: 'sqlite', schema }),
  emailAndPassword: { enabled: false },
  databaseHooks: {
    user: {
      create: {
        before: async (user) => {
          if (allowedEmails.length > 0 && !allowedEmails.includes(user.email.toLowerCase())) return false
        },
      },
    },
  },
  socialProviders: { github: { clientId, clientSecret, scope: ['repo', 'read:user', 'user:email'] } },
})

What happens on a sign-up:

The allowlist is an environment variable. Changing it is a deploy, reviewed like any other change. With a hosted service, the same rule would live in a dashboard or a webhook outside the repository.

Which Better Auth plugins do we run in production?

Each plugin is code in the repository, so the list is easy to check:

• Our starter template: tanstackStartCookies and the Polar billing plugin (checkout and customer portal, a customer created on sign-up). Polar is only added when the token exists.
• A client web app: Better Auth inside Payload CMS, with admin, organization, twoFactor, emailOTP, magicLink, multiSession and the passkey plugin.
• A client's online marketplace: a separate auth service on MongoDB with magicLink and oidcProvider. The marketplace's other apps sign in through it, like through any OpenID Connect provider.

Three databases, three setups, one library. That is the part we value most: the same library fits SQLite on the edge, Postgres behind a CMS and MongoDB in a separate service.

When is Clerk the better choice?

Clerk makes sense when you want sign-in done this week and nobody on the team should own auth code. Prebuilt components save you the screens. Clerk sends the emails and patches the service. For a prototype, the free plan is generous: 50,000 monthly retained users per app, Pro at $25 a month, and $0.02 per user from 50,001 to 100,000 (Clerk pricing, as of 2026-10-24).

Lock-in is smaller than people think. Clerk lets admins export users, including hashed passwords, as a CSV (Clerk docs, as of 2026-10-24). The data is not held hostage. What takes work is everything wired to it: sign-in UI, session checks on the server and any user data you copied into your own tables.

One more fact worth weighing. Better Auth joined Vercel on July 7, 2026. Their post says: "Vercel shares our commitment to keeping auth open source, framework and platform agnostic." (Better Auth blog). The MIT license stays what it is. We note it the way we note any owner change of a dependency we rely on.

What do you take on when you own auth?

Owning auth is not free of work. It moves the work to your team. Before you pick Better Auth, go through this list:

The last point is the cheapest insurance. Our starter runs Playwright tests for exactly that: the login form renders, sign-up works, and the dashboard redirects to login without a session.

How we expose app data to AI agents on top of this auth is covered in How to build an MCP server, and when you should not.

Need auth that stays in your database?

We build web apps where users, sessions and permissions live in the client's own database, as part of custom web application development. Code, data and infrastructure belong to the client from day one. AI writes all of our code today, and a senior is accountable for the result. Since 2023 we have delivered 15+ production projects.

We get back to you within two business days, and together we pick what to fix first.

If you'd rather talk first, book a 15-minute meeting with Filip.

Where do your users live today, and could you query them with one SQL join?

Frequently asked questions

What is the difference between Better Auth and Clerk?

Better Auth is an open source TypeScript library that stores users and sessions in your own database. Clerk is a hosted service that stores them for you and gives you prebuilt sign-in UI. The trade is control and no per-user bill versus less code to own.

Is Better Auth free?

Yes. Better Auth is MIT licensed. You pay for what it runs on: your database, your hosting and the email service that sends verification links and magic links.

How much does Clerk cost?

As of 2026-10-24, the Clerk Hobby plan is free with a limit of 50,000 monthly retained users per app, Pro is $25 a month ($20 billed annually), and users 50,001 to 100,000 cost $0.02 a month each. Check clerk.com/pricing for the current numbers.

Should I migrate from NextAuth to Better Auth?

For new projects, yes: Auth.js is now maintained by the Better Auth team, and they recommend Better Auth for new work. For a NextAuth app that works, we do not migrate just for the sake of it. We switch when the app needs a feature NextAuth does not have.

Can I leave Clerk later?

Yes. Clerk lets admins export users, including hashed passwords, as CSV from the dashboard. What takes work is the rest: sign-in UI, session checks and any user data you synced into your own tables.