Comparison
Clerk or Auth.js? The self hosted answer moved
The verdict
For a new product, pick Clerk - and do not pick Auth.js. Auth.js has been in security-patch-only maintenance since September 2025, is now maintained by the Better Auth team, and its own guidance points new projects at Better Auth instead. Clerk raised its free tier to 50,000 monthly retained users in February 2026, which covers most products for a long time, then charges a 25 dollar base plus 2 cents per user above that. The crossover arrives near 100,000 users, where Clerk is roughly 1,025 dollars a month against a self-hosted Postgres at 25 to 50 dollars. Below that line, buy it. Above it, own it.
Clerk's billing unit deserves attention because it is narrower than the industry norm. It bills monthly retained users, and a user only counts once they return to your application at least 24 hours after signing up. Signup spikes, bot registrations and one-time visitors do not bill. Compared against a provider metering plain monthly active users, that difference is worth real money on a product with a wide funnel and a narrow retention curve.
Clerk vs Auth.js on cost, features and maintenance
Prices were current in mid-2026 and vendors change them, so verify before budgeting. The arithmetic is the point: at 100,000 users, 50,000 billable at 2 cents plus the 25 dollar base is 1,025 dollars a month, every month, forever.
| Dimension | Clerk | Auth.js |
|---|---|---|
| Maintenance status | Actively developed and commercially funded, with unlimited applications now included on every plan. | Security patches only since September 2025. No new features. This is the single most important row. |
| Cost to 50,000 users | Free. The February 2026 change raised the included allowance from 10,000 to 50,000 retained users. | Free, plus whatever your database costs. There is no per-user component at any scale. |
| Cost at 100,000 users | Around 1,025 dollars a month on Pro. Business starts at 300 dollars and adds SOC 2 reporting and priority support. | Unchanged. A Postgres instance holding a hundred thousand user rows is a 25 to 50 dollar line item. |
| Time to first login | An afternoon. Drop-in components handle sign-in, sign-up, profile and organization switching. | A day or two. You build the UI, the adapter, the session strategy and every email yourself. |
| MFA and passkeys | Built in, including recovery codes and device management. This is a large part of what you are buying. | Not included. Two-factor authentication and passkeys are yours to implement and maintain. |
| Organizations | A first-class model with invitations, roles and switching, though it is a paid add-on of roughly 100 dollars a month. | No concept of organizations. Multi-tenancy is entirely your schema and your middleware. |
| Exit cost | High. Clerk holds the user records and session state; leaving means an export plus a forced re-authentication for everyone. | Near zero. Users, accounts and sessions are rows in your own database that any library can read. |
When each option is the right call
Choose Clerk when
- You are pre-revenue or under 50,000 retained users, where the bill is zero and the time saved is days.
- The product is B2B with teams, invitations and roles, and Clerk's organization model matches your domain exactly.
- You need MFA, passkeys or SSO on a deadline and building them yourself is not a realistic use of the sprint.
- Nobody on the team wants to own password reset flows, session rotation, or the incident response if credentials leak.
- An enterprise buyer asks for SOC 2 evidence and you would rather point at a vendor report than build a program.
Choose Auth.js when
- You already run it, it works, and it only uses OAuth providers with database sessions. Security patches still ship, and rewriting working authentication is one of the worst uses of a sprint.
- The project is a side product or internal tool with two or three social providers, no MFA requirement, and no roadmap.
- You need users in your own database for regulatory or data-residency reasons and are not ready to change libraries this quarter.
- Vendor cost at scale is a founding constraint and you have the team to own the security surface deliberately.
For anything new that fits these rows, evaluate Better Auth first. It is where Auth.js development moved, and it ships two-factor authentication, passkeys, organizations and role-based access control as plugins.
Why this matchup changed shape in 2026
For years the honest framing was "convenience versus control": Clerk if you wanted speed, NextAuth if you wanted your users in your own database and no per-seat bill. That framing broke when the Auth.js maintainers handed the project to the Better Auth team and put it into security-patch-only mode. Choosing a library today whose own maintainers are steering new users elsewhere is a decision you will have to revisit, and revisiting an authentication choice is expensive precisely because everything else depends on it.
Better Auth filled the gap fast: a 5 million dollar seed round, more than 26,000 GitHub stars, and over 150,000 weekly npm downloads. Functionally it is what people wanted Auth.js v5 to become - TypeScript-first, framework-agnostic, users in your own database, with two-factor authentication, passkeys, organizations and RBAC available as plugins rather than as homework. If your reason for considering Auth.js was self-hosting rather than Auth.js specifically, that reason now points somewhere else.
Clerk, meanwhile, made itself much harder to argue against for small products. Raising the free allowance five-fold to 50,000 retained users means a great many applications never pay anything, and metering retained rather than active users means a marketing spike does not generate an invoice. The catch is unchanged and worth stating plainly: you do not own the user records, and the cost curve is linear in a number you want to grow. Model your bill at ten times your current users before you commit, not at today's number.
The migration risk deserves its own sentence. Moving off Clerk is possible - user data exports - but password hashes and live sessions are the sticking points, so realistically every user re-authenticates on cutover, and any social login mapping has to be rebuilt. That is survivable for a consumer app and genuinely painful for a B2B product with enterprise customers and SSO configurations. Pricing and documentation are at clerk.com and authjs.dev.
Where this fits in a full stack
The authentication layer covers Better Auth, Supabase Auth, WorkOS and Auth0 alongside these two, with the compliance and SSO features that decide enterprise deals. For a product where auth sits next to billing and multi-tenancy, the SaaS stack guide makes the whole set of calls together.
If you are trying to get a first version in front of users this week, the weekend MVP stack guide picks the fastest defensible option. Other close calls are in the comparisons index.