Two weeks ago, my team made the call to replace our authentication system. Not because it was broken — it worked fine. But it was holding us back in ways that became obvious only when we tried to move fast.
Why We Decided to Change
Our original auth was a custom solution built years ago by someone who left before I joined. It stored passwords with MD5 (yes, MD5), had no support for OAuth, and the session management was a mess of global variables and database tables that nobody fully understood.
It worked. But every time we added a new feature that needed user identity, we spent hours tracing through tangled code. New developers couldn’t understand it. Security audits gave us warnings. We were essentially building on a foundation that felt shaky.
What We Chose
After some research, we went with Supabase Auth. Here’s why:
- It handles OAuth out of the box (Google, GitHub, etc.)
- Row-level security ties directly to user IDs
- The free tier is generous enough for our current scale
- It plays well with our existing PostgreSQL database
We also considered Auth0 and Firebase. Auth0 felt enterprise-heavy and expensive. Firebase meant locking into their ecosystem. Supabase gave us flexibility without the overhead.
The Migration Wasn’t Smooth
Here’s the honest part — it took us two weeks, not one. Here’s what slowed us down:
1. Migrating Existing Users
We had 12,000 users with hashed passwords. We couldn’t reverse the MD5 hashes. The solution: we forced a password reset on login for everyone. It created some support noise, but it was the cleanest path.
2. Updating All the Services
We had authentication logic spread across our API, our frontend, and (embarrassingly) some stored procedures. We had to update every single place that touched user sessions. A few places we missed caused bugs that appeared only in production.
3. Testing Edge Cases
Things we didn’t think about: what happens when a user is deleted while they have an active session? What about token refresh timing? We found bugs in the second week that we hadn’t anticipated.
What We Gained
Now that it’s done, here’s what changed:
- New OAuth login works in a day instead of a week
- Security audits pass without manual explanations
- New developers understand the auth flow in hours, not days
- We can focus on building features instead of maintaining auth code
Would I Do It Again?
Yes. But I’d plan for three weeks instead of two. If your auth system is causing friction, don’t wait until it becomes a blocker. The migration cost is real, but so is the cost of staying on something that slows you down.
The lesson here isn’t about Supabase specifically. It’s about recognizing when a foundational piece is limiting your team. Sometimes the right move is to rip off the band-aid and spend two weeks doing work that should have been done years ago.