Clerk vs Supabase Auth vs Better-Auth — Which to Pick for India MVP (2026)

By Rohit Raj — Founding Engineer, 6 years shipping production MVPs · LinkedIn

## TL;DR

For a typical India MVP at 10K MAU, Supabase Auth wins on price (included in the $25/month Pro plan you are already paying for Postgres), Better-Auth wins on lock-in and cost at scale ($0 forever if you self-host on your own Postgres), and Clerk wins on time-to-ship if you can afford ~$200/month at 10K MAU. Skip Clerk if your runway is under 12 months or your auth needs are basic CRUD. Skip Better-Auth if your team has never owned a Postgres migration. Default for the 6-week MVP playbook in 2026: Supabase Auth, then graduate to Better-Auth on the same Postgres when MAU crosses 50K.

The short answer: pick the auth provider that matches the cost ceiling you can stomach 18 months from now. Clerk's pricing model is per-MAU, so success is what kills you — at 50K MAU you are looking at ₹85,000/month for a feature your users do not see. Supabase Auth keeps the flat-fee math sane up to 100K MAU. Better-Auth removes the bill entirely but moves the operational cost to your team. There is no universally best answer; there is only the one that fits your runway, team size, and lock-in tolerance.

The structural reason this matters now: Better-Auth crossed 28K GitHub stars in Q1 2026 and shipped a Postgres adapter that runs on the same database your app already uses. That changes the calculus — until late 2025, picking an OSS auth library meant accepting Auth.js's session-cookie weirdness or NextAuth's ergonomics. Better-Auth fixed both. Combined with Supabase's Mumbai region launch in November 2025 closing the latency gap with Clerk, the 2026 decision is no longer "hosted or pain" — it is "pick your tradeoff axis: cost, lock-in, or time."

I ran this comparison last month for a clinic-booking client deciding between staying on Clerk Pro or migrating to Supabase Auth. The app has 11,400 MAU, OTP-only signup (no social login), and roughly 2,400 SMS verifications/month for new signups and password recovery. Here is the actual monthly cost on each at three scale points.

The 50K MAU column is where the conversation usually starts hurting. ₹11.64 lakh/year for a feature that signs people in is a hard number to defend at a board meeting when your AWS bill is ₹3.2 lakh and your salaries are ₹85 lakh.

The Clerk SMS line is the killer for Indian OTP signup flows. Clerk routes SMS through Twilio at retail US rates (~$0.04/verification to India). MSG91 or Gupshup over a direct DLT-registered route in India costs ₹0.40-₹0.60 (~$0.005-$0.007) per SMS — roughly 6x cheaper. Supabase and Better-Auth both let you wire your own SMS provider; Clerk locks you into their routing unless you pay for the Enterprise plan ($1,500+/month) that unlocks custom SMS.

The Better-Auth column assumes one weekend of setup and ~2 hours/month of ops. That is realistic for a competent Next.js team. If your team is still figuring out what a JWT is, do not pick Better-Auth — the savings will be eaten by debugging session edge cases at 2am.

Auth migrations are the worst kind of migration because every active user is forced to log in again, and any user you cannot migrate is gone. So the lock-in cost is not the export tool — it is the percentage of users you lose during the cutover.

Clerk lock-in is the highest. Clerk does export password hashes (bcrypt) and user metadata via their Backup Codes API, but the export does not include active sessions, OAuth tokens from social providers, or 2FA backup codes. When I helped a fintech migrate 32,000 users off Clerk to Supabase Auth in February 2026, we lost 11.4% of users in the 14-day re-verification window because they did not respond to the migration email. That is 3,648 paying users gone — at their ₹400/month ARPU that is ₹14.6 lakh/year of recurring revenue evaporated to save ~₹8 lakh/year on Clerk fees. The math did not work.

Supabase Auth lock-in is medium. The user table lives in your Postgres (auth.users), password hashes are standard bcrypt, and the schema is documented. Migration to Better-Auth on the same Postgres is mostly a column-rename operation — you write a Postgres function that copies auth.users.encrypted_password to better_auth.user.password and updates the app's session cookie name. I did this last month for a SaaS client in 4 hours, zero user-facing re-verification. The trick is staying on the same Postgres instance; if you also need to migrate the database, that is a separate problem.

Better-Auth lock-in is essentially zero. The schema is yours, the password hashing is configurable (bcrypt or argon2id), and the session table is just rows. You can move to Auth.js, custom JWT, or even back to Clerk by dumping the user table and re-inviting. The cost is the operational burden you took on — you now own keeping the auth code patched against CVEs, monitoring for credential-stuffing attempts, and rotating session secrets.

I built MyFinancial on a custom auth layer (pre-Better-Auth, in 2024) for exactly this reason — the app handles linked bank accounts, and I did not want a third party with the keys to the kingdom. The 2026 version of that decision is: use Better-Auth, get the same lock-in profile, and skip writing the boring parts yourself.

Cost and lock-in are the durable axes, but the day-to-day comparison is developer experience. Here is what each one feels like when you are 3 weeks into a 6-week MVP and trying not to lose a day to auth.

Clerk's DX is the genuinely best of the three. The Next.js SDK is two lines (<ClerkProvider>, auth()), the dashboard is polished, and pre-built components for sign-up, sign-in, user profile, and organizations work out of the box. For an MVP where the founder has a deadline and the auth UI is throwaway, Clerk shaves ~3-5 days off the build. The cost of that is that you cannot easily diverge from Clerk's opinions — adding a custom signup field that goes into your own table requires their unsafeMetadata API and a webhook to sync back, which is a recipe for race conditions I have personally hit twice.

Supabase Auth is "good enough" with one footgun. The @supabase/ssr package handles cookies correctly in Next.js App Router as of v0.7 (April 2026 — it was a mess before that). The pre-built UI components in @supabase/auth-ui-react are functional but ugly; you will rebuild them. The footgun is that RLS policies and Auth are coupled tightly — if you misconfigure a row-level-security policy, queries silently return empty arrays instead of errors. I wrote about that specific bug class here. Once you have a debugging rhythm, it is fine.

Better-Auth is the new contender that actually delivers. The TypeScript-first API, schema-driven plugins (passkeys, 2FA, magic links, OAuth), and the fact that it runs on your existing Postgres makes it the cleanest fit for a Next.js + Postgres MVP. The catch is that it is young (1.x as of April 2026) — the docs are improving but you will hit edge cases the docs do not cover, and the community is ~5% the size of Clerk's. If you Google an obscure error, you might be the first person to hit it. For a senior team this is fine; for a junior team it is a tax.

Real time-to-first-login benchmark from three recent builds:

• Clerk + Next.js App Router + Google OAuth: 22 minutes from npm install to working login
• Supabase Auth + Next.js + email/password: 47 minutes (mostly cookie/SSR debugging on first attempt)
• Better-Auth + Next.js + email/password: 38 minutes (schema migration + first session)

For a 6-week MVP, none of these matter much — you eat the difference once. Picking on DX alone is a junior mistake.

The "India latency" row is the one founders miss. Clerk's auth backend runs out of US-East primarily; even though your app is in Mumbai, every auth round-trip hits Virginia. For OTP signup that means 600-900ms of latency on the "send code" step — slow enough that users hit "resend" twice and you pay for 3 SMS instead of 1. Supabase Mumbai and Better-Auth on a Mumbai-based Hetzner box both cut this to under 50ms.

For a payment-flow MVP where re-auth happens on checkout, those 600ms compound into measurable conversion loss. I have not benchmarked it formally but anecdotally on the clinic-booking client we saw checkout-completion lift from 71% to 78% after the Clerk-to-Supabase migration, which probably included a latency component alongside the UX redesign.

Despite the price tag, Clerk is the right pick in three specific scenarios. Calling these out so you do not over-optimize on cost for a build that does not need to.

Scenario 1: B2B SaaS with organizations + invitations on day one. Clerk's Organizations primitive (teams, roles, invitations, billing-per-org) is genuinely best-in-class and would take 2-3 weeks to build properly on Supabase or Better-Auth. If your MVP is a B2B tool where the second user invited matters more than the first, Clerk shaves enough time off that the ~₹15,000/month at 10K MAU is worth it. The math flips around 25K MAU — at that scale you can afford a part-time engineer to migrate.

Scenario 2: Funded startup with <12 month runway and a non-technical founder. If you are paying a contractor $150/hour and the contractor does not know auth deeply, putting them on Clerk for 6 weeks saves you 3-5 days of debugging — that is $3,600-$6,000 saved. At 10K MAU you would pay roughly $1,400/year for Clerk. Easy win. The trap is forgetting to migrate before the per-MAU bill outgrows the original savings; set a calendar reminder for when you hit 30K MAU.

Scenario 3: You need SOC 2 Type II in the next 90 days. Clerk has SOC 2 Type II and a customer-facing security review pack ready to ship to enterprise buyers. Supabase has SOC 2 Type II too, but the way you configure it (RLS policies, separate Postgres schema for PII) requires more documentation work. Better-Auth puts the full SOC 2 burden on you. If a Series A check is gated on enterprise compliance and you have 90 days, Clerk is the fastest path.

Scenario where Clerk is clearly wrong: consumer mobile app with OTP-only auth, India-heavy users, target ARPU under ₹500/month. The SMS cost alone makes Clerk untenable, and the organizations/SOC-2/polish features are wasted on a consumer flow. Default to Supabase Auth here; if you need to squeeze further at scale, migrate to Better-Auth.

Run this checklist top-to-bottom; pick the first one that fires.

1. Is your MVP B2B with multi-tenant orgs needed on day one? → Clerk, plan migration at 25K MAU.
2. Are you a senior team (or solo founder who has owned Postgres in production)? → Better-Auth, self-host on Hetzner or your existing AWS RDS.
3. Are you on Supabase already for the database? → Supabase Auth, it is free in the Pro plan.
4. Is your auth flow OTP-heavy with India users and ARPU under ₹1,000/month? → Supabase Auth or Better-Auth, never Clerk (SMS cost kills you).
5. Do you need SOC 2 Type II in <90 days? → Clerk, accept the price.
6. Default if none of the above: Supabase Auth. Graduate to Better-Auth on the same Postgres at 50K MAU.

A few crosscut rules:

• Never start with custom JWT in 2026. The Better-Auth library now exists; rolling your own is a junior mistake.
• Always wire MSG91 or Gupshup for India OTP, regardless of which provider you pick (where the provider allows BYO SMS). Twilio India retail rates are 6-8x what direct DLT routes cost.
• Set a migration trigger before you ship. Write down the MAU number at which you will migrate off your initial pick, and put it in your runway model. The conversation "we should migrate" never happens if it is not pre-committed.
• Pick the auth provider before you pick the framework. Auth has the deepest reach into your codebase; switching is more expensive than rewriting your UI library. Pick auth first, then build around it.
• Do not pay for "advanced features" in the free tier evaluation. Every provider's free tier is generous enough to ship an MVP. The conversation that matters is what 50K MAU costs, not what the free tier includes.

Auth provider choice is one of the few decisions in an MVP build that has real long-term consequences. Pick wrong and you either pay 10x more than necessary or hit a migration cliff at the worst possible moment (usually right after a fundraise when you are supposed to be growing, not re-architecting).

I have built MVPs on all three of these stacks in the last 18 months. The pattern that ships fastest and survives 12-18 months without a rewrite is: Supabase Auth for the first six weeks, with a written migration plan to Better-Auth at 50K MAU. Clerk only when the B2B Organizations primitive or the SOC 2 timeline actually pays for itself.

If you are starting from scratch and want the auth decision made for you alongside the rest of the stack — Postgres, deployment, payment integration, observability — that is exactly what the 6-Week MVP Sprint packages: a senior engineer making these picks once, defensibly, so you do not lose three days to auth-provider research while your runway burns.

For founders who want a long-term technical partner to make these calls plus build the product, the Hire a Founding Engineer in India engagement model covers the same decision-making depth at a monthly retainer instead of project rate.

Either way: pick one of the three auth providers above, set the migration trigger, and stop reading auth-comparison blog posts. The product is what wins.