De Supabase a Better Auth pasando por Clerk

• En 2023, Val Town dejó Supabase y migró a una configuración de base de datos más tradicional: movió la base de datos a Render y la autenticación a Clerk, pero como esa arquitectura externalizaba la responsabilidad de los usuarios y las sesiones de una forma que no encajaba, hace un mes cambió a Better Auth
• Clerk propuso eliminar la tabla de usuarios, pero Val Town, por sus funciones sociales, necesitaba mostrar con frecuencia contenido de varios usuarios, nombres de usuario y avatares, y entre los límites del API de Clerk y la sincronización, terminó con la complejidad práctica de operar dos tablas de usuarios
• Como Clerk también se encargaba de renovar las sesiones, se convirtió en un punto único de falla; cuando Clerk tenía una caída, no solo fallaban el inicio y cierre de sesión, sino que incluso a los usuarios ya autenticados se les dificultaba usar todo el sitio; desde mayo de 2025, según su página de estado, la disponibilidad se percibía entre 99% y 99.9%
• Val Town no reescribió todo de inmediato porque el SDK de Clerk, sus funciones administrativas, la prevención de abuso y el dashboard le resultaban útiles, pero sí estableció como criterio no volver a confiar la gestión de sesiones a un tercero
• Better Auth encajó por la calidad del código, la integración con frameworks y un núcleo open source independiente; Val Town mantuvo soporte simultáneo para Clerk y Better Auth durante unas dos semanas, aceptando dos tipos de cookies para hacer una migración gradual de sesiones

---

Contexto del cambio

• En 2023, Val Town dejó Supabase y migró a una configuración de base de datos más tradicional, reemplazando la base de datos por Render y la autenticación por Clerk
• A finales de 2023 se abrió un issue diciendo que había que dejar Clerk, y ese issue se cerró hace un mes con la migración a Better Auth
• Clerk y Supabase son servicios exitosos que levantaron 50 millones de dólares en inversión y 100 millones de dólares con una valuación de 5 mil millones, respectivamente, pero la arquitectura de Val Town chocaba fuertemente con lo que Clerk esperaba
• El proceso de migración incluyó muchos atajos, bugs y caídas, y en particular quedó claro que el problema central era la estructura en la que Clerk intentaba sustituir tanto la tabla de usuarios como la tabla de sesiones

Problema central: externalizar la tabla de usuarios y la tabla de sesiones

• Por qué era difícil usar Clerk como tabla de usuarios

  • Clerk impulsó con fuerza la idea de eliminar la tabla de usuarios, como en su artículo de 2021 “Consider dropping your users table” y su video de 2023 “DELETE your Users table”
  • Al inicio de la migración, Val Town pensó que podía traer desde el API de Clerk, cuando hiciera falta, datos como preferencias del usuario, URL del avatar y correo electrónico
  • El SDK de Clerk tenía en rootAuthLoader una opción loadUser que pedía datos del usuario mientras resolvía la autenticación de toda la aplicación, y en desarrollo funcionaba bien
  • En producción, el límite de ese endpoint era de 5 solicitudes por segundo sumando toda la cuenta y todos los usuarios, y este problema después se resolvió con la eliminación de la opción
  • Un servicio con funciones sociales como Val Town necesita mostrar en muchas páginas contenido de otros usuarios, nombres de usuario y avatares, así que no encajaba con la suposición de la UI por defecto de Clerk de que el usuario solo leería desde el JWT su propio avatar y su propia configuración
  • La recomendación de Clerk fue sincronizar los avatares y otra información entre Clerk y la tabla de usuarios de Val Town, lo que en la práctica dividió la autoridad sobre la misma información en dos lugares y creó la complejidad de operar dos tablas de usuarios

• La complejidad del flujo de registro creada por la sincronización con webhooks

  • Para sincronizar los datos de Clerk con la base de datos de Val Town había que usar webhooks, y el proceso de registro se volvió complejo y delicado
  • Durante un breve momento después del registro, podía ocurrir que un usuario tuviera una cuenta en Clerk pero todavía no una fila en la base de datos de Val Town
  • Como Val Town requiere nombre de usuario, también podía darse el estado en que el usuario ya tenía cuenta en Clerk y fila en la base de datos, pero todavía no había completado su cuenta
  • La configuración del usuario tuvo que dividirse entre elementos gestionados por Clerk, como el método de autenticación, y elementos que necesitaba Val Town, como el nombre de usuario y la configuración del editor

La estructura de sesiones en la que Clerk se volvió un punto único de falla

• Las sesiones de usuario basadas en cookies normalmente duran poco y se renuevan de forma continua, para que puedan invalidarse con rapidez
• En esta estructura, cada ciertos minutos el usuario tenía que intercambiar la cookie de sesión por una nueva, y un subdominio de Val Town reenviaba la solicitud a Clerk para hacer la renovación
• Val Town no tenía tabla de sesiones ni asumía responsabilidad sobre las sesiones
• Este enfoque puede ser conveniente si se quiere evitar la responsabilidad de la autenticación, pero cuando Clerk se caía no solo se rompían el inicio y el cierre de sesión: incluso los usuarios ya autenticados podían quedar sin poder usar todo el sitio
• Clerk tuvo caídas frecuentes y prolongadas, y según su página de estado desde mayo de 2025, la disponibilidad se percibía entre 99% y 99.9%
• La confiabilidad de un sistema complejo queda atada al mínimo de la confiabilidad combinada de sus componentes importantes
• Además de estos dos grandes problemas, hubo otros bugs e issues relacionados con Clerk; la mayoría terminaron corrigiéndose, pero hubo que lidiar con el “Stale Issue Bot”, que cerraba issues automáticamente

Por qué no hicieron el cambio de inmediato

• El trabajo de “migrar de X a Y” puede afectar la velocidad de desarrollo y la estabilidad mental del equipo, así que Val Town evitó reescribir cosas salvo que fuera realmente necesario
• Clerk ofrecía SDKs para tecnologías que Val Town usaba, como Remix, Fastify y Express, y seguía bastante bien los cambios de esos frameworks
• Las funciones administrativas y de prevención de abuso de Clerk ayudaban a resolver problemas de soporte al cliente y a bloquear usuarios fraudulentos
• El caso de uso donde Clerk encajaba especialmente bien era el de apps relativamente simples, centradas en frontend, sin elementos sociales y sin necesidad de tabla de usuarios
• Era fácil empezar y el precio era manejable, y el dashboard de Clerk también era bastante bueno
• No había muchas alternativas de autenticación, y entre las soluciones open source muchas eran antiguas y estaban en la práctica abandonadas
• Las plataformas de autenticación como servicio implican riesgo de proveedor, y podían repetirse problemas similares a los de Clerk
• Val Town no quería construir autenticación completamente por su cuenta desde cero y exponerse a vulnerabilidades nuevas y bochornosas, pero tampoco quería ceder demasiada responsabilidad al proveedor
• En particular, quedó establecido el criterio de no volver a confiar la gestión de sesiones a terceros

Elección de Better Auth y forma de la migración

• Better Auth cumplía muchas condiciones por su alta calidad de código, su buena integración con varios frameworks y por ser un proyecto open source independiente realmente utilizable
• Better Auth también sigue siendo una base de código grande y compleja desarrollada en su mayor parte por una sola empresa, así que el riesgo de proveedor no desaparece
• Pero sí desaparece la dependencia de que un tercero deba seguir en línea para que funcionen las sesiones y la autenticación de usuarios
• AuthKit de WorkOS también era un candidato fuerte y muy pulido, pero después de pasar por dos proveedores, se volvió importante una alternativa que funcionara de manera independiente y tuviera un núcleo open source
• El dashboard de Better Auth y sus add-ons de pago también encajaban con las necesidades de Val Town
• Val Town administra directamente todos los datos, y los plugins exponen un API en el sitio de Val Town para que el dashboard de Better Auth pueda obtener información y hacer una gestión ligera de usuarios
• El servicio de pago “Infrastructure” de Better Auth, en la forma en que lo usa Val Town, en la práctica es casi stateless y no interviene en la gestión de sesiones
• Durante la transición, Val Town mantuvo soporte simultáneo para Better Auth y Clerk por unas dos semanas
• Todos los endpoints que procesaban autenticación aceptaban ambos tipos de cookies, y la página de login entregaba una sesión de Better Auth, permitiendo que los usuarios migraran gradualmente a Better Auth
• Como se trataba de una tarea relacionada con seguridad, hubo que leer, reescribir y probar cuidadosamente todo el código, y el código final de autenticación puro con Better Auth fue escrito por completo de forma directa
• Better Auth también encaja bien con Vals, y para agregar autenticación al código de Val Town se puede usar el starter template de Better Auth

Lecciones que quedan

• El tiempo de actividad de un proveedor upstream afecta directamente el tiempo de actividad del servicio, así que hay que evaluar con cuidado cuánto riesgo se está asumiendo
• Aunque un producto encaje bien en muchos casos de uso y haya tenido un gran éxito, puede no ser adecuado para un problema específico
• El entorno de software cambia rápido, y una solución adecuada que no existía en cierto momento puede aparecer un año después

[GN⁺]

Comentarios en Hacker News

• Ojalá alguien más inteligente que yo me explique por qué habría que entregar la tabla de usuarios de Postgres a un proveedor tercero
  No entiendo qué tiene de tan difícil mantener directamente una tabla en una VM de Hetzner. No es pagos, solo son datos con unos cuantos campos

  • Cuando son unos cuantos campos, sí, pero pronto deja de ser tan simple
    Se le agregan SSO, SAML, SCIM, OIDC, OAuth, autenticación de dos factores, autenticación sin contraseña, tokens de verificación, etc. y, para cada función, además te piden integraciones adaptadas con sistemas ampliamente usados. En nuestra empresa, durante un tiempo, la mitad del tiempo de los ingenieros de soporte se iba en resolver toda clase de problemas de SSO de un sistema de autenticación hecho por nosotros
  • A mí tampoco me queda muy claro. Siempre me pregunté por qué existe algo como Supabase, y parece mostrar qué tan alejado está el mundo del desarrollo frontend de una forma de construir cosas que sea básicamente simple y segura
  • ¿No quieres hacer crecer tu carrera hacia arquitecto? Dibujas una caja, le pones User Management y le conectas un SaaS como Clerk, y puedes asumir que ya está gestionado
    Entonces todos los requisitos para los que sientes “esto no aporta valor aunque lo implemente yo” los puedes empujar a esa caja negra mágica
  • La gente tiene muchísimo miedo de arruinar la autenticación y terminar hackeada. Por eso tienden a pasarle esa responsabilidad a un tercero y dejar de preocuparse por ello
  • Yo estoy igual de confundido. A grandes rasgos, cuando los requisitos no son tan amplios, parece más fácil operar tu propia base de datos y manejar la autenticación con algo como Django
    A escala enterprise tal vez sea distinto

• Soy Bereket, de Better Auth. Yo también empecé Better Auth justo para resolver este problema, y después se convirtió en una empresa
  Siempre da gusto ver que otros obtienen el mismo valor. Todavía queda mucho por hacer, así que me gustaría saber qué se podría mejorar

  • Me pregunto si hay planes para dar soporte a backends en Python. O si hay alguna forma en que podamos usarlo
  • ¿Crees que la autenticación en el navegador es compleja porque el navegador no hace lo suficiente?

• Es peor que decir: “la dura lección que uno aprende al construir sistemas complejos es que su confiabilidad es el mínimo de la confiabilidad de sus partes clave”
  En realidad, la disponibilidad total es el producto de la disponibilidad de todos los componentes en la ruta crítica. Si el software, la capa de autenticación y el proveedor cloud tienen 99% de disponibilidad cada uno, y si con que se caiga uno de los tres ya se cae el servicio, entonces la disponibilidad final es solo de 97%. Si tienes 11 componentes así, ya no te queda ni un solo “nueve” en disponibilidad. Por eso es importante reducir componentes y elegir soluciones más confiables, y me alegra que este equipo haya tomado ese camino

  • Aprendí esto por las malas en la gran caída de Cloudflare de la vez pasada. Yo ni siquiera usaba Cloudflare, pero la clave pública de Auth0 que usaba para validar JWT se servía detrás de Cloudflare, así que toda la cadena de autenticación se rompió y mi app quedó inutilizable durante horas

• También leí con gusto la publicación anterior sobre migración de Supabase (https://blog.val.town/blog/migrating-from-supabase)
  Hacen falta más textos honestos y buenos sobre decisiones de ingeniería a largo plazo; ojalá sigan escribiendo en el blog

• Hace poco pasé por un proceso parecido. Empecé con Stack Auth, pero no se podía usar en producción por límites de velocidad extremadamente agresivos y mal rendimiento, e incluso cuando no pegaba contra esos límites seguía siendo lento
  Después me cambié a WorkOS AuthKit y funciona mucho mejor, además de soportar funciones enterprise útiles. Aun así, para un proyecto nuevo me atrae más Better Auth. Sincronizar el estado de un proveedor de autenticación externo con el estado de mis usuarios es un criadero de bugs, y ayuda mantener la menor cantidad de estado posible en el proveedor de autenticación, pero aun así algo queda. Renovar tokens de acceso JWT cada pocos minutos también es otra fuente de bugs y, si controlas la autenticación directamente, sinceramente no hace falta. WorkOS no tiene una API completa y está construido sobre la idea de un producto por cuenta de facturación y una cantidad fija de entornos (staging, production y uno más si se lo pides a soporte). Cosas como las URL de redirección también hay que meterlas en una lista permitida desde el dashboard, y no parece haber una forma fácil de que un agente lo maneje. Externalizar la autenticación no me parece que tenga mucho sentido. Cuanto menos repartas el estado entre varios servicios, menos problemas tendrás. Hay casos inevitables, como pagos, o cuando necesitas una base de datos especializada por rendimiento, pero para autenticación realmente no hay razón para eso si existe una buena librería. También se dice que usando un servicio puedes empezar más rápido, pero los problemas que yo tuve con servicios de autenticación no estaban relacionados con gran escala y, en su mayoría, aparecieron antes siquiera del lanzamiento

• Estoy usando Clerk y estoy bastante insatisfecho. No tiene un RBAC decente
  Los roles están ligados a la organización y no al usuario en sí, así que no puedes tener algo como un administrador global y tienes que hacer apaños guardando pares clave-valor arbitrarios en metadata. En las últimas semanas o meses también ha habido varias caídas, y cada vez falló toda la app. Me lo pensaría dos veces antes de volver a usarlo

• Me alegra muchísimo haber elegido Lucia al principio. La librería está prácticamente terminada, y la reemplazaron con documentación y pequeñas utilidades sobre cómo gestionar y alojar la autenticación por tu cuenta
  La autenticación siempre se presenta como algo grande y aterrador que no puedes manejar tú mismo, pero después de pasar como una semana aprendiendo cómo funcionan la seguridad y el salting básico, me sentí mucho más seguro sobre cómo funciona todo en conjunto

  • https://lucia-auth.com/
    Me acuerdo cuando retiraron la librería y la convirtieron en material de aprendizaje para implementar autenticación desde cero. Fue una gran decisión y tengo muchísimo respeto por el autor

• La comparación entre Clerk y Better Auth casi podría decirse que es injusta. Uno es un servicio y el otro es una librería, así que es comparar peras con manzanas
  Todo servicio de terceros que se integra en tu stack se convierte en una carga de responsabilidad, y las librerías también, pero en menor medida. Ya es hora de que más servicios sean reemplazados por librerías, y Better Auth demuestra muy bien ese enfoque. Me gusta que sea una librería que se integra con el frontend, el backend y la base de datos

• Los textos de Tom siempre valen la pena
  ¿Alguien se acuerda de Auth0 y passportjs? Los cambios en los servicios de autenticación no se detienen nunca, pero supongo que no se puede evitar porque los estándares también siguen cambiando

  • OAuth 2.x y OIDC no han cambiado tanto. Yo todavía uso Passport.js junto con Firebase