From Supabase to Clerk to Better Auth
Val Town's CTO recounts their migration from Clerk to Better Auth, detailing the architectural pain points and reliability issues encountered with Clerk, particularly concerning user table management and session dependency. This narrative resonates with developers navigating the complex landscape of third-party authentication services. It highlights the critical trade-offs between convenience and control when outsourcing core application functionality.
The Lowdown
This article details Val Town's authentication journey, moving from Supabase's built-in auth to Clerk, and ultimately to Better Auth. The author, Tom MacWright, explains that despite Clerk's success and funding, it proved unsuitable for Val Town's needs due to fundamental architectural conflicts.
- Core Architectural Conflict: Clerk's design as both a users table and a sessions table created issues, especially for applications with social features that need to query user data frequently and reliably.
- Rate Limiting Woes: Clerk's API suffered from severe rate limits (5 requests/second per account) when trying to load user data, making it impractical for displaying multiple user profiles or avatars.
- Data Synchronization Complexity: Syncing Clerk's user data to Val Town's database via webhooks led to convoluted signup flows and a split authority over user settings.
- Single Point of Failure: Clerk's handling of session management meant that their outages directly impacted Val Town's site availability, even for logged-in users, leading to frequent and prolonged downtime.
- Switch to Better Auth: Better Auth was chosen for its high code quality, good framework integrations, and open-source core, allowing for greater control and independence from vendor uptime.
The author concludes by emphasizing the importance of carefully evaluating upstream provider dependencies for critical infrastructure like authentication, recognizing that successful products may still not fit every specific use case.
The Gossip
Clerk's Critical Conundrums
Many commenters echoed the author's frustrations with Clerk, citing its reliability issues, lack of essential features (like proper RBAC or audit logs), and increasing complexity. Users reported frequent downtimes impacting their applications and described the libraries as bloated, obfuscated, and difficult to debug due to intricate dependencies.
The Auth Autonomy Debate
A significant discussion revolved around the merits of offloading authentication to a third-party service versus managing it in-house or using open-source libraries. Some argued against giving up control of the 'users table' to a external provider, preferring the stability and customizability of self-hosted solutions or robust web frameworks. Others acknowledged the convenience of services but stressed the importance of vendor risk and reliability.
Alternative Auth Adventures
Commenters proposed and praised various alternatives to Clerk. Better Auth received positive mentions for its hackability and integration capabilities, with its founder even participating in the discussion. Other suggested solutions included Lucia (a library for self-hosting auth), Auth0 for its reliability, and leveraging built-in authentication features of established web frameworks like Laravel, ASP.NET Core, Ruby on Rails, and Django.