Val Town 身份验证迁移：从 Supabase、Clerk 到 Better Auth，背后有何艰难抉择？

从 Supabase 到 Clerk，再到 Better Auth：Val Town 身份验证迁移背后的艰难抉择

2026 年 5 月 6 日，Tom MacWright 分享了 Val Town 在身份验证方面的迁移历程。2023 年，Val Town 从 Supabase 迁移到更传统的数据库设置，用 Render 作为数据库，Clerk 进行身份验证。然而，到 2023 年末，他们提出停用 Clerk 的问题，一个月前切换到 Better Auth 后得以解决。

Clerk 非常成功，刚筹集 5000 万美元，Supabase 也以 50 亿美元估值筹集 1 亿美元。但 Val Town 还是很高兴切换到 Better Auth，因为使用 Clerk 期间经历了诸多艰难，其架构与 Clerk 预期严重冲突。

核心问题

核心问题在于，Clerk 试图同时充当用户表和会话表。将用户表外包给第三方服务存在两大问题。

Clerk 作为用户表替代品不理想：它有严格速率限制且不太可靠。最初切换时，以为可从 Clerk 的 API 加载用户数据，开发环境运行良好，但生产环境中该端点速率限制为每秒 5 次请求，且针对整个账户。这对 Val Town 社交功能影响大，为解决问题，不得不使用 Webhook 将 Clerk 数据同步到数据库，使注册过程复杂，用户设置也需分开。

Clerk 成为用户会话单点故障：基于 Cookie 的用户会话需不断刷新，由 Val Town 子域名将请求传递给 Clerk 刷新。若 Clerk 出现故障，整个网站瘫痪，且 Clerk 经常出现长时间故障，自 2025 年 5 月以来，其正常运行时间在 99% - 99.9% 之间波动。除这两个主要问题，还遇到其他漏洞和问题。

三年左右的时间

若情况糟糕，为何不立即切换？一方面，不想让“从 X 切换到 Y”成为习惯，坚持决策有助于提高开发速度、让团队保持理智，且写批评文章不如开发有趣积极。另一方面，Clerk 有优点，为使用的技术提供 SDK，跟上框架更新，管理和反滥用措施有一定作用，适合相对简单、以前端为主且无社交功能的应用程序。此外，身份验证优秀选项不多，替换 Clerk 门槛高，开源解决方案陈旧，身份验证即服务平台有供应商风险，掌握合适技术控制权不易。

Better Auth 登场

Better Auth 从一开始就满足很多要求，代码质量高，与不同框架集成效果好，作为独立开源项目实用。虽存在供应商风险，但不再依赖第三方保证会话和用户身份验证正常运行。排名第二的是 WorkOS 的 AuthKit，但经历两次供应商切换后，找到能独立运行且核心开源的解决方案很重要。Better Auth 的管理控制台和付费附加功能设计巧妙，管理自己的数据，付费服务基本无状态，不参与会话管理。

大语言模型在过渡期间帮忙，两周过渡期间同时支持 Better Auth 和 Clerk，最终完全使用 Better Auth 的身份验证代码是完全手写的。Better Auth 与 Vals 配合得好，可尝试其入门模板为 Val Town 代码添加身份验证功能。

一路走来学到很多，依赖上游供应商保证系统正常运行时，应认真考虑风险。有些产品虽出色成功，但可能不适合特定问题。软件行业变化快，当下不存在的解决方案，一年后可能出现。

Val Town 正在招聘，欢迎加入团队一起打造编程的未来，可查看开放职位。