Better Auth vs Clerk vs Auth.js for Indie Hackers in 2026

Picking auth is one of those decisions that feels small and then quietly shapes your codebase for years. And the choice changed more in the last year than most people realize. If you Google this, half the comparisons you'll find are describing an ecosystem that no longer exists.

Here's the shift. In late 2025, Auth.js (the library formerly known as NextAuth.js) joined forces with Better Auth. The Better Auth team now maintains it, and Auth.js is officially in maintenance mode: security patches only, no new features. So the old "NextAuth vs Better Auth" framing is basically over. They're the same camp now, with Better Auth as the future and Auth.js as the legacy version you keep around if you already use it. Around the same time, Clerk quietly raised its free tier from 10,000 users to 50,000.

That leaves a cleaner question for 2026: do you want to own your auth or rent it? Better Auth (and its predecessor Auth.js) keep your users in your own database and cost nothing per user. Clerk runs auth as a service, ships fastest, and charges per user once you scale. I've wired up auth more times than I'd like to admit, so here's the honest three-way with real pricing.

The Quick Verdict

Short version: start new projects on Better Auth if you want to own your stack, or Clerk if you want to ship today and you're comfortable renting. Only pick Auth.js if you already run it.

What Actually Changed in 2026?

This is the part that reframes everything. Auth.js had been stuck: version 5 sat in beta for over two years, and its lead maintainer stepped back in early 2025. Rather than let it fade, the Better Auth team took it over. They've committed to keeping Auth.js patched for security, but their guidance is direct: start new projects on Better Auth.

The practical effect is that the field narrowed from three real options to two, plus a legacy. For a new build, you're choosing between a self-hosted library you control (Better Auth) and a hosted service you pay for (Clerk). Auth.js is now the thing you migrate away from, not toward. One security note that applies to all of them: the 2025 Next.js middleware vulnerability (CVE-2025-29927) showed that protecting routes with middleware alone is bypassable, so check auth in the actual server component or route handler regardless of which library you choose.

Better Auth

Better Auth is the one I'd start a new project on today. It's a TypeScript-first, framework-agnostic authentication library, not a service. The auth code lives in your codebase, the sessions live in your Postgres, and there's no external API to call or go down. It launched in 2024, reached v1.0 quickly, and hit v1.6 by May 2026, with around 28,000 GitHub stars and a YC batch behind it. The momentum is real.

It covers the full surface out of the box: email and password, social logins, magic links, passkeys, and two-factor auth. The parts that usually hurt for SaaS, organizations, teams, role-based access control, and admin tooling, ship as official plugins rather than things you bolt on yourself. It's database-agnostic and works cleanly with Prisma or Drizzle, and it recently added stateless sessions without a database, which was the one gap Auth.js used to hold over it.

Cost is the kicker. The library is free under MIT, so you only pay for the Postgres it writes to, roughly $10 to $30 a month, and that number barely moves whether you have 5,000 users or 500,000. There's no per-user meter, ever.

Who should skip it? You're the one running it, so you own hosting, updates, and uptime. There are no pre-built UI components, so you build your own sign-in and account pages, which is real hours compared to Clerk dropping in a component. Enterprise features like SAML SSO you implement yourself. And the ecosystem, while growing fast, is younger, so you'll occasionally hit a thinner doc or a missing integration. If you want auth handled for you today, this asks more of you upfront.

Clerk

Clerk is the one you reach for when you want auth done by lunch. It's a hosted service with the best developer experience in the category: drop in pre-built React components like <SignIn />, <UserButton />, and <OrganizationSwitcher />, wire up the hooks, and you have polished, production-grade auth with social login, MFA, and multi-tenant organizations in minutes instead of days. For a solo founder racing to a first version, that time saving is the whole pitch.

The pricing changed in your favor recently. The free tier now covers 50,000 monthly retained users, up from 10,000, which takes most early products well past launch for free. Pro is $25 a month (or $20 billed annually), includes that same 50,000, then charges $0.02 per retained user above it. The "retained" part matters: Clerk only counts users who come back at least a day after signing up, so a viral burst of one-time signups doesn't spike your bill. Compliance (SOC 2, GDPR) is on every tier, and one enterprise SSO connection is included on Pro. For the managed-provider angle more broadly, I compared it with the others in Clerk vs Auth0 vs Supabase Auth.

Who should skip it? Two reasons. First, cost at scale: past 50,000 users the meter runs, and at 100,000 you're looking at about $1,025 a month for auth alone. Second, lock-in: your users live in Clerk's US-hosted database, not yours, so you're renting both the service and the home for your user data. If data residency matters or you want to own that table, Clerk fits awkwardly. It's a fast on-ramp, not always a long-term home.

Auth.js (NextAuth)

Auth.js is the library a huge slice of the JavaScript world already runs, and if you're one of them, this section is the only one that matters: you can stay. It's free, open source, and now maintained by the Better Auth team for security and critical fixes. Its strengths are still real: 80-plus OAuth providers, database adapters for Prisma, Drizzle, TypeORM, Supabase, and others, and a JWT session strategy that works at the edge without a database call. It pairs naturally with a Next.js app, where it spent its whole life as NextAuth.

But be clear-eyed about the status. Auth.js is in maintenance mode. No new features are coming. It never had built-in two-factor auth, passkeys, role-based access, or multi-tenancy, so those still mean extra libraries or custom code. The v5 split-config pattern trips people up, and the official migration guide to Better Auth exists precisely because the maintainers expect new energy to go there.

Who should skip it? Anyone starting fresh. Building a new 2026 project on Auth.js means starting on a frozen foundation when its own maintainers are pointing you at Better Auth instead. The only good reason to choose it today is that you already have it wired into a working app and there's no pressing need to migrate. If it works, leave it. If you're greenfield, don't start here.

Own It or Rent It: The Cost at Scale

The clearest way to see the tradeoff is to follow the bill as you grow. Better Auth and Auth.js cost only the database they write to, so their line stays flat. Clerk is free for a long time, then climbs per user.

At 100,000 users, the gap is roughly a thousand dollars a month, which is about one engineer-day of cost every month for the auth layer alone. That's not an argument against Clerk. It's an argument for knowing where the line crosses. The common 2026 pattern is to ship on Clerk to reach product-market fit fast, then migrate to Better Auth or Supabase Auth somewhere around the 50,000-user mark when the bill starts catching your accountant's eye.

What's the Migration Actually Like?

Since that ship-then-move path is so common, it's worth knowing the friction before you bank on it. Leaving Clerk means exporting your users, and Clerk supports exporting bcrypt-hashed passwords, so people don't all have to reset, while social-login users just re-authorize on first sign-in. The real work isn't the data, it's swapping Clerk's components and hooks for your own UI and Better Auth's client calls. You can do that incrementally by running both side by side during the cutover rather than in one risky switch.

Moving from Auth.js to Better Auth is the better-trodden route now, with an official migration guide. Developers are honest that it takes real planning, since the two model sessions and accounts differently, so it's a careful port rather than a find-and-replace. The upside is you're moving toward the actively developed library, not away from one. Either way, the lesson teams keep repeating is to pick the auth you can live with at scale earlier than feels necessary, because migrating auth is never the sprint you were hoping to run that week.

How Do You Choose the Right One?

Start with whether you're building new or maintaining old, then weigh speed against ownership.

flowchart TD
    A[Choosing auth] --> B{Already running Auth.js and it works?}
    B -- yes --> C[Stay on Auth.js, no urgent migration]
    B -- no --> D{Need working auth today, fine renting?}
    D -- yes --> E{Under 50K users for a while?}
    E -- yes --> F[Clerk]
    E -- no --> G{Want to own users and cost long-term?}
    G -- yes --> H[Better Auth]
    G -- no --> F
    D -- no --> H

Concrete scenarios. Brand new SaaS and you want to own your auth, your user data, and a flat cost curve? Better Auth. Racing to validate an idea and you'd rather not build sign-in screens this week? Clerk, and plan to revisit at scale. Already shipped on NextAuth and it's humming? Stay put, it's still patched.

The Verdict: Which Should You Use?

For a new project where you care about control and long-term cost, use Better Auth. It's free, it keeps your users in your own database, it has the modern feature set Auth.js never grew, and it's where the whole ecosystem is now heading. You pay for it in setup time and the UI you build yourself, but you own the result and the bill never surprises you.

Use Clerk when speed is everything and you're early. Nothing ships polished auth faster, the 50,000-user free tier carries you a long way, and the retained-user billing protects you from viral spikes. Just treat it as a fast on-ramp and know that the meter and the data-residency tradeoff are waiting past 50,000 users.

Stick with Auth.js only if you already run it. It's maintained for security, it works, and migrating a working app for no reason is wasted effort. But don't start anything new on it, because its own maintainers are telling you not to.

The honest meta-point is that the question got simpler this year, even if the marketing pages haven't caught up. It's own versus rent. Better Auth if you want to own your auth, Clerk if you'd rather rent it and move fast, and Auth.js only as the legacy you already happen to have. Pick on that axis, not on a benchmark or a logo. Wired up auth on one of these recently? Tell me how it went over on @devtoolpicks.