本文翻译自 From Supabase to Clerk to Better Auth，原载于 Hacker News。
背景：三次迁移的来龙去脉
2023 年，Val Town 的创始人写过一篇文章，讲述他们如何从 Supabase 迁移到更传统的数据库架构。当时他们大量使用了 Supabase 的功能，包括其内置的认证系统。迁移时，他们选择了 Render 替代数据库，Clerk 替代认证服务。
然而好景不长，到 2023 年底，团队内部就提交了一个 issue：离开 Clerk。这个 issue 终于在一个月前被关闭——他们切换到了 Better Auth。
需要先说明的是，Clerk 本身是一个成功的产品。他们刚融了 5000 万美元，有大量满意的用户。Supabase 也在近期以 50 亿美元估值融了 1 亿美元。这些数据是硬核事实，个人的使用体验无法否认产品的商业成功。
但对于 Val Town 的特定场景来说，切换到 Better Auth 确实是正确的决定。
核心问题：Clerk 试图成为你的用户表和会话表
Clerk 的核心理念是同时管理你的 用户表（users table） 和 会话表（sessions table）。他们 2021 年发过一篇博客叫 “Consider dropping your users table”，2023 年还有个 YouTube 视频叫 “DELETE your Users table”。作者对此的建议是：强烈建议你不要这么做。
把用户表交给第三方服务，会带来两个大问题。
问题一：Clerk 作为用户表的替代品并不称职
Clerk 的 API 有严格的速率限制（rate limiting），可靠性也不够高。
刚切换到 Clerk 时，团队假设可以随时通过 Clerk 的 API 加载用户数据——头像、邮箱、用户设置等。Clerk 的 SDK 也提供了 rootAuthLoader 中的 loadUser 选项，开发环境下一切正常。
但到了生产环境，这个接口的速率限制是每秒 5 次请求——而且是整个账号、所有用户共享的。 这是一个在开发环境中根本发现不了的坑。
这个限制对 Val Town 的社交功能打击尤其严重。社交网站需要在很多页面上展示其他用户的头像和用户名。Clerk 的默认 UI 假设是：用户只看到自己的头像和信息，这些都可以从 JWT token 中获取。但像 Val Town 这样的社交平台完全打破了这个假设。
官方建议的解决方案是：通过 webhook 将 Clerk 的数据同步到自己的数据库。但这意味着：
- 信息有了两个权威来源，本质上就是两张用户表的复杂性
- 注册流程变得曲折——用户在某个瞬间有 Clerk 账号但没有数据库记录
- 用户设置被割裂：Clerk 管认证策略，自己管用户名和编辑器设置
问题二：Clerk 成了所有用户会话的单点故障
基于 Cookie 的用户会话通常是短期的，需要不断刷新，以便能快速失效。这意味着每隔几分钟，用户就需要交换会话 cookie 获取新的。
在 Val Town 的架构中，当用户的登录会话需要刷新时，请求从 Val Town 的子域传给 Clerk，由 Clerk 完成刷新。Val Town 自己没有会话表，也不参与会话管理。
如果 Clerk 挂了，整个网站就挂了。 Clerk 的故障不仅影响登录/登出流程，它会让已经登录的用户也无法使用网站。而且 Clerk 确实经常挂，每次挂的时间还不短。从 2025 年 5 月的数据来看，它的运行时间在两个九到三个九之间徘徊（即 99%–99.9%），之前的情况也不容乐观。
构建复杂系统时你学到的一个硬道理：系统的可靠性等于其关键组件可靠性的最小值。
为什么撑了三年才换？
看到这里你可能会问：既然这么糟糕，为什么不早点换？
首先，切换基础设施是有成本的。频繁做”从 X 切到 Y”的决策不利于开发效率和团队心态稳定。
其次，Clerk 也有做得好的地方：
- 提供了 Val Town 使用的所有技术栈的 SDK（Remix、Fastify、Express）
- 跟进了这些框架的版本更新，这本身就是个全职工作
- 管理后台和反滥用措施对客服和安全防护都有帮助
Clerk 特别适合的场景是：相对简单、偏前端的、没有社交功能的应用。这类应用不需要用户表，用 Clerk 上手极快，价格实惠，管理界面也不错。
但认证领域的好选择确实不多。很多开源认证方案年久失修；Auth-as-a-Service 平台有同样的供应商风险。技术控制的度很难拿捏——既不想从零构建认证系统暴露安全漏洞，也不想把太多责任外包给第三方。
Better Auth：最终的选择
Better Auth 在多个维度上满足了 Val Town 的需求：
- 代码质量高，与各种框架的集成做得好
- 可以作为独立的开源项目使用，不依赖第三方服务在线
- 虽然仍是主要一家公司开发的复杂代码库，存在一定的供应商风险，但会话管理和用户认证不再依赖第三方保持在线
WorkOS 的 AuthKit 是一个强有力的备选。WorkOS 值得信赖，AuthKit 也做得很精致。但经过两次供应商切换后，团队更看重独立运行、开源核心的方案。
Better Auth 的商业模式也很有意思：管理仪表盘和付费附加功能的设计很巧妙。Val Town 管理自己的所有数据，一个插件在 Val Town 的站点上提供 API，让 Better Auth 的仪表盘可以拉取信息做轻量级用户管理。Better Auth 的付费服务（叫 “Infrastructure”）在使用方式上基本是无状态的，不参与会话管理。
迁移策略：双轨并行
值得一提的是，在 LLM 的辅助下，团队选择了一条更复杂但更安全的迁移路径：同时支持 Better Auth 和 Clerk 两周。每个处理认证的端点都能接受两种 cookie，用户慢慢迁移到 Better Auth，因为登录页面提供的就是 Better Auth 类型的会话。
安全相关的代码当然需要仔细审阅、重写和测试。最终的纯 Better Auth 认证代码是完全手写的。
几点思考
对于中国开发者来说，这篇文章有几个值得注意的点：
-
认证架构的选择要慎之又慎。国内不少团队也在使用 Authing、Casdoor 等认证服务，同样需要评估单点故障和供应商锁定风险。
-
社交类产品的认证需求与普通应用不同。如果你的产品需要展示大量用户信息（头像、用户名等），把用户表完全交给第三方可能是个坑。
-
开源认证方案在成熟度上已经有了长足进步。Better Auth、Logto、Casdoor 等项目都值得关注，它们提供了更好的控制权和灵活性。
-
双轨迁移是处理认证切换的好策略。虽然复杂度更高，但可以平滑过渡，避免一刀切带来的风险。
关键收获
- 不要轻易把用户表和会话表完全交给第三方服务，尤其是对你的核心业务至关重要的部分
- 系统的可靠性受限于最薄弱的环节——选择供应商时要评估其 SLA
- 认证方案选型要结合自身业务特点，别人的成功不等于适合你
- 开源自托管方案在控制权和可靠性方面有天然优势
- LLM 在复杂迁移任务的辅助能力不容忽视