Choosing Your Post-Platform Auth: Supabase Auth vs. Clerk vs. Auth.js vs. WorkOS

Your MVP ran beautifully on Firebase—until the day it didn't. Maybe your project vanished without warning. Maybe you discovered your user data sits in a format you cannot export. Maybe you realized one vendor controls your authentication, your database, and your ability to operate at all.

Platform lock-in puts your entire business at the mercy of decisions you cannot influence. The question now: which authentication solution lets you migrate off-platform while preserving ownership of your hosting, your data, and your future?

Think of these criteria as the three keys to your own front door: lose one, and you're still locked out. The four options below are evaluated against all three, moving from strongest overall fit to most specialized.

Supabase Auth: Strong Self-Hosting, Full Data Portability, Predictable Pricing

Supabase Auth meets all three criteria. The platform runs on open-source components, and the entire stack—including authentication—can be self-hosted using Docker. Your user credentials, session data, and authentication logic live in a Postgres database you can export, migrate, or replicate with standard tools like pg_dump.

The architecture bakes in data portability. Because Supabase Auth stores everything in standard Postgres tables, you own your data in a format that works with any infrastructure. No proprietary export process. No vendor-specific schema to decode. Just SQL.

Pricing scales transparently. The free tier includes 50,000 monthly active users. The Pro plan at $25 per month extends that to 100,000 MAUs, with additional users charged at $0.00325 each. You can calculate your costs at any scale before you commit—no surprises when your product takes off.

Self-hosting does require more operational overhead than a pure SaaS solution. You're trading convenience for control. But that trade eliminates the risk of sudden suspension or policy changes. If Supabase the company disappeared tomorrow, your authentication system would keep running on your own servers. That's the kind of insurance platform refugees learn to value.

Clerk: Excellent Data Portability and Transparent Pricing, No Self-Hosting Path

Clerk meets two of the three criteria fully and fails the third. The platform offers no self-hosting option—your authentication runs entirely on Clerk's infrastructure.

Data portability is strong. Clerk provides full data exports from the dashboard at any time, no questions asked. You can extract your user records, metadata, and authentication history whenever you need them.

Pricing is transparent and published. The free Hobby tier supports up to 50,000 monthly retained users per app. The Pro plan costs $25 per month—or $20 per month billed annually—with the same 50,000 MRUs included. Beyond that threshold, additional users cost $0.02 per MRU per month, with volume discounts at higher tiers.

Clerk's MRU model only counts users who return at least 24 hours after signing up. If you have high churn or lots of one-time signups, you'll often pay less than traditional MAU billing would charge.

For founders whose primary concern is speed to market rather than infrastructure ownership, Clerk is excellent. Pre-built UI components, social login, multi-factor authentication, and enterprise SSO work out of the box with minimal configuration. But if you require the ability to run authentication on your own servers, the lack of a self-hosted path is disqualifying. You're trading one dependency for another—hopefully a better one, but a dependency nonetheless.

Auth.js: Complete Self-Hosting and Data Ownership with Zero Pricing Risk

Auth.js meets all three criteria, but with a different trade-off than Supabase. Auth.js (formerly NextAuth.js) is a free, open-source authentication library that runs entirely on your own infrastructure. No vendor, no monthly fee, no external dependency beyond the OAuth providers you integrate.

You must self-host—there is no managed option. Your user sessions, credentials, and authentication logic live wherever you deploy your application. Your servers. Your cloud account. Your hardware.

Data portability is absolute. You control the database schema, the storage location, and the export process. There's no vendor to request data from because you already have it all.

You pay nothing—zero usage tiers, zero overage charges. No pricing changes to monitor. Your only costs are the infrastructure you provision yourself.

The trade-off is development time. Auth.js provides the primitives—session management, provider integrations, database adapters—but you assemble them into a working system. No pre-built UI components. No managed user dashboards. No support team to call when something breaks at 2 AM.

The library supports multiple frameworks including Next.js, SvelteKit, Express, and Qwik, making it adaptable to most modern stacks. Founders with engineering resources gain maximum control. Those without may spend a weekend debugging a session-cookie mismatch instead of shipping features.

WorkOS: Data Portability and Pricing Transparency for Enterprise-Focused Products

WorkOS meets two of the three criteria and targets a specific use case: B2B SaaS companies selling to enterprises that require SSO integration.

Self-hosting is not available. WorkOS is a fully managed service, and your authentication runs on their infrastructure.

Data portability follows standard practices. WorkOS provides access to your user and organization data through APIs, and you can export records as needed.

Pricing is transparent and published, with a model optimized for enterprise sales. The first million active users on WorkOS AuthKit are free, with additional users charged at $2,500 per million per month. Enterprise SSO connections cost $125 each for the first 15 connections, with volume discounts reducing that to $65 per connection when you reach 51-100 connections.

This per-connection model makes costs predictable when you know how many enterprise customers you'll serve. If your customers are large organizations with IT departments that mandate SAML or OIDC authentication, WorkOS simplifies a genuinely complex integration.

If you're building a consumer product or a B2B tool for small businesses, the per-connection model offers less value. Supabase or Clerk will serve you better.

Your Next Step

Before you commit to any option, run this audit:

Document exactly what user data you need to migrate—email addresses, password hashes, OAuth tokens, session records, and any custom metadata.

Estimate your monthly active user count for the next 12 months. Calculate the total cost of each option at that scale, including any enterprise SSO connections you anticipate needing.

Assess your team's technical capacity honestly. If you have engineers who can maintain infrastructure, Auth.js or self-hosted Supabase become viable. If you need all engineering time focused on product features, Clerk or managed Supabase may be worth the reduced control.

Test your top two choices in a development environment. Pay particular attention to the data export process—run a full export and verify you can restore it independently. The time to discover export problems is before you've migrated 50,000 users.

Start with the audit. Open a document right now and list every piece of user data your current platform holds. That list is your migration checklist—and your insurance policy against repeating the lock-in mistake.