Clerk vs Supabase Auth vs Auth.js for AI-Built Apps

Every vibe-coded app hits the same wall. The Lovable project or Bolt scaffold shipped with Supabase Auth because the template wired it up. It worked fine while there were twelve users, three of whom shared your last name. Then a paying customer asked whether you support SSO from their Okta tenant, or your Supabase project started showing auth logs that looked nothing like your app code, or you realised that the sign-up screen cannot be restyled without rewriting the form from scratch. That is the moment founders start comparing Clerk, Supabase Auth, and Auth.js in earnest, and it is the moment most comparison articles fail them. The ranking content treats this as a features checklist. It is not. It is a decision about how much of the auth surface you want to own, how your pricing will bend under user growth, and whether your next ten customers are consumers or companies.

This article walks through the three realistic options for founders who hit Supabase Auth's ceiling, the cost curves that matter, and the four inflection points that determine which provider actually fits: the 10K MAU breakeven, the SSO and directory-sync moment, the Auth.js maintenance tax, and the organisations gap that bites every B2B product.

The three realistic options, in plain terms

Clerk is a managed authentication service. You install their SDK, drop their pre-built React components into your app, and stop thinking about sign-up screens, password resets, magic links, social logins, and session management. They handle the infrastructure, the UI, the edge cases, and the security updates. You pay per monthly active user above a free tier, and the price climbs as you grow.

Supabase Auth is bundled with the Supabase platform most vibe-coded apps already use. If your database is Supabase, your auth tables already live in an auth schema next to your application data. Row-level security policies can reference auth.uid() directly, which makes per-user data isolation nearly automatic. You pay for the Supabase project, not per authenticated user, which keeps costs flat as you scale. You build your own sign-up and sign-in screens, or lean on their minimal UI helpers, and you get magic links, OAuth, email plus password, phone OTP, and SAML SSO on the paid tiers.

Auth.js, formerly NextAuth, is a library. It is free, open source, and extraordinarily flexible. You plug it into your Next.js or other Node runtime, point it at a database adapter, wire up an email provider, pick your session strategy, and ship. Nothing is hosted for you. Nothing is managed for you. Every edge case is yours to handle, which is fine until it is not.

These three options are not interchangeable. Clerk is a service you rent. Supabase Auth is a feature of a database you are already paying for. Auth.js is a codebase you adopt. The decision rests on which of those models fits your stage, your customers, and your tolerance for invisible infrastructure work.

The 10K MAU breakeven point nobody calculates

Here is the cost story most articles skip. Clerk's free tier covers ten thousand monthly active users, which sounds generous and usually is for a prototype. The moment you cross that line, Clerk's Pro plan kicks in at twenty-five dollars per month plus two cents per additional monthly active user. At fifty thousand MAU that works out to roughly eight hundred and twenty-five dollars per month. At one hundred thousand MAU you are looking at close to two thousand dollars per month before the enhanced auth add-ons that most B2B products end up needing. Organisations, SSO, MFA enforcement, and device management can push the bill further.

Supabase Auth, by contrast, is bundled into the Supabase plan. A Supabase Pro project at twenty-five dollars per month gives you one hundred thousand monthly active users included. You scale into compute and bandwidth costs as your database grows, but the per-user auth line item does not exist. For a consumer application with a hundred thousand users, that gap is not rounding. It is the difference between a tool you pay attention to and a tool you never think about.

Auth.js flattens the curve further. There is no per-user cost, no plan tier, nothing to upgrade. You pay for your database, your email provider, and your engineering time. This sounds like the cheapest option on paper, and sometimes it is, but the cost model is deceptive because it shifts the spend from a vendor invoice to hours you did not plan to spend.

The breakeven point to watch is roughly ten thousand monthly active users. Below it, price barely matters and you should choose on developer experience and B2B feature fit. Above it, Clerk starts to feel expensive unless you have clear evidence that its managed UX is driving conversions or saving you engineering headcount. This is the single most useful framing for founders trying to decide, and it is the framing the ranking content almost never offers.

The SSO and directory sync inflection

The second decision point has nothing to do with your total user count. It has to do with the first enterprise customer who asks whether you support SAML single sign-on from their identity provider, and shortly after, whether you can provision users automatically from their directory using SCIM. These two questions are the moment every B2B founder discovers the true price difference between the three options.

Clerk handles SAML SSO and SCIM directory sync natively once you are on the right plan. Organisations get a tenant-scoped SSO configuration, administrators can map claims, and user provisioning flows in from Okta or Microsoft Entra without code changes on your side. For a product selling into mid-market and enterprise, this is the feature that justifies Clerk's pricing in one conversation. The alternative is to build and maintain this yourself, which most vibe coders cannot do and should not try.

Supabase Auth supports SAML SSO on its paid plans. It does not yet support SCIM directory sync as a native feature. For most deals this is survivable, but when a buyer insists on automated deprovisioning driven by their HR system, you end up bolting WorkOS or a similar directory-sync provider onto your Supabase stack. That is a reasonable architecture and it is how many scaled products run, but it adds a vendor and a code path. The total cost is often still lower than Clerk at high volume, which is the point.

Auth.js gives you no native SSO and no directory sync. You can bolt WorkOS onto Auth.js the same way you would bolt it onto Supabase, but you are paying for the flexibility with engineering time on both sides of the integration. For products that will never sell to enterprise, this does not matter. For products that will, Auth.js's flexibility becomes a liability the moment procurement reviews your security questionnaire.

If you know you will be selling into companies that use Okta, Entra, or Google Workspace as their identity provider within the next twelve months, Clerk's pricing starts to look like a feature rather than a tax. If your customers are individuals or small teams, this inflection point may never arrive, and Supabase Auth or Auth.js will serve you indefinitely.

The Auth.js maintenance tax the library will not tell you about

Auth.js is a beautiful library. It is also a trap for founders who underestimate what a full authentication system actually contains. The library handles the happy path for OAuth, credentials, and magic links. It does not handle, and does not pretend to handle, the long tail of responsibilities that turn auth from a feature into a system.

You own the database schema and the migration strategy when Auth.js evolves. You own the email deliverability story, which means picking a provider like Resend or Postmark, handling bounces, and making sure magic link emails do not land in spam. You own rate limiting on your sign-in endpoints, because credential stuffing attacks will find your app within days of going live. You own bot protection, CAPTCHA integration, and account lockout policies. You own password reset flow UX, session expiration edge cases, and the decision of whether to use JWT sessions or database sessions, with the trade-offs that follow. You own multi-factor authentication, because Auth.js does not ship an opinionated MFA flow. You own passkeys, which remain partially experimental. You own the response when a user's account is compromised and you need to invalidate sessions across every device.

None of this is a reason to avoid Auth.js. It is a reason to be honest about the ledger. Clerk charges you in dollars for the work it does on your behalf. Supabase Auth bundles a subset of that work into your database bill. Auth.js charges you in engineering hours, and the bill grows every time a security advisory drops or a new browser deprecation lands. For a vibe-coded app built by a non-technical founder with a freelance developer on contract, that bill is almost always higher than the managed alternatives once you factor in the opportunity cost of not shipping product.

There is a narrow band where Auth.js is genuinely the right answer. Technical founders who already run their own infrastructure, products with unusual auth requirements that no managed provider supports cleanly, and consumer apps where per-user cost would be prohibitive all fit the profile. If that is not you, the apparent zero cost of Auth.js is usually an accounting illusion.

The Organisations gap that decides most B2B choices

Almost every software-as-a-service product needs the concept of a team. A user belongs to an organisation, an organisation has members with roles, administrators can invite new members, an invitation produces a pending user who accepts and joins, and billing is typically attached to the organisation rather than the individual. This is the single most replicated piece of scope in B2B SaaS and the single most underestimated piece of scope in vibe-coded apps.

Clerk ships Organisations as a first-class primitive. The data model is built in. The invitation flow is built in. The pre-built components include an organisation switcher, a members management screen, and an invitations table. Role checks are available server-side through claims on the session token. For a B2B product, this saves somewhere between two and six weeks of design, build, and test work depending on the complexity of the role model.

Supabase Auth does not ship Organisations. You model teams in your own tables, wire foreign keys from users to memberships, build the invitation flow, and write row-level security policies that check organisation membership for every query that touches tenant data. This is not hard, but it is not free. It is the plumbing that founders discover two months into a product and wish they had known about on day one.

Auth.js, like Supabase Auth, treats organisations as out of scope. You build it yourself, with the added complication that you are also building the rest of the auth surface.

For founders building B2C products, this gap is irrelevant. For founders building B2B SaaS, the choice often resolves on this single axis. Clerk's Organisations primitive is what makes its pricing defensible for early-stage B2B teams. The question is not whether you will eventually need this scope. The question is whether you would rather pay Clerk to provide it or write it yourself with RLS policies.

A decision framework that actually fits vibe-coded apps

Put the inflection points together and the framework falls out. For a consumer app with under ten thousand users, Supabase Auth is usually the right default. The price is already paid, the RLS integration is tight, and the UI surface you have to build is small. If you want managed UI and have budget, Clerk is defensible, but it is not obviously better for pure B2C at this stage.

For a B2B SaaS under ten thousand users, Clerk is usually the right default, even with the cost. The Organisations primitive alone saves weeks, the SSO-ready posture shortens enterprise sales cycles, and the managed UI lets a solo founder ship a credible product without becoming an auth expert.

For any app crossing ten thousand users, the decision reopens. A consumer app at fifty thousand MAU should sanity-check whether Clerk's UI is driving conversion or whether Supabase Auth with a custom UI would serve the same business need at a fraction of the cost. A B2B app at fifty thousand MAU with enterprise deals in flight should probably stay on Clerk unless the engineering team has the capacity to run Supabase plus WorkOS reliably.

For technical founders building consumer apps that must minimise infrastructure cost, Auth.js is a fine answer if you are prepared for the maintenance work. For everyone else, it is usually a distraction from the product.

Migration paths, because the first choice is rarely the last

None of these providers is a one-way door. Migrating from Clerk to Supabase Auth is mechanically straightforward because Clerk exports password hashes in a compatible format. Users who signed in with social providers can re-authenticate on first visit after migration. Migrating from Supabase Auth to Clerk works the same way in reverse, since Clerk's user import API accepts bcrypt hashes directly. Sessions invalidate, but active users accept a single re-login without much friction. Migrating from Auth.js to either managed provider is the easiest of the three because you already own the users table and can script exactly what you need.

The practical advice is to choose the provider that fits your current stage rather than one you pick to avoid a future migration. Auth migrations are boring, well-understood projects that take a week or two of focused engineering. Bad provider choices cost you months of ill-fitting product work.

Where WitsCode fits

Founders shipping AI-built apps rarely want to become auth experts, and they rarely want to spend a weekend reading Clerk, Supabase, and Auth.js docs side by side trying to reverse-engineer the decision. WitsCode offers an auth architecture advisory that picks the right provider for your stage, your B2B posture, and your migration risk, and then implements the chosen stack end to end. That includes Organisations modelling, row-level security wiring, SSO readiness, and a migration plan for the users already in your Supabase project. If you are staring at your auth.users table wondering whether to keep it, replace it, or bolt something on top of it, that is exactly the conversation we have. → Book an auth architecture call.