Do Supabase, passando pelo Clerk, para o Better Auth

• A Val Town deixou o Supabase em 2023 e migrou para uma configuração de banco de dados mais tradicional: banco no Render e autenticação no Clerk. Mas a estrutura de terceirizar a responsabilidade por usuários e sessões não se encaixava, então há um mês mudou para o Better Auth
• O Clerk propunha eliminar a tabela de usuários, mas a Val Town precisava exibir com frequência conteúdo, nomes de usuário e avatares de vários usuários por causa de recursos sociais. Por causa dos limites da API do Clerk e da necessidade de sincronização, isso acabou criando a complexidade de operar na prática duas tabelas de usuários
• Como o Clerk também cuidava da renovação de sessão, ele virou um ponto único de falha. Quando o Clerk saía do ar, não só login e logout quebravam, como até usuários já autenticados tinham dificuldade para usar o site inteiro. Desde maio de 2025, a percepção com base na página de status era de uma disponibilidade entre 99% e 99,9%
• A Val Town não reescreveu tudo imediatamente porque os SDKs, recursos administrativos, proteção contra abuso e dashboard do Clerk eram úteis, mas passou a adotar o princípio de não voltar a confiar a gestão de sessões a terceiros
• O Better Auth atendia aos requisitos em qualidade de código, integração com frameworks e um núcleo open source independente. A Val Town deu suporte simultâneo a Clerk e Better Auth por cerca de duas semanas, aceitando dois tipos de cookie para fazer uma migração gradual de sessões

---

Contexto da migração

• Em 2023, a Val Town saiu do Supabase e migrou para uma configuração de banco de dados mais tradicional, substituindo-o por Render no banco de dados e Clerk na autenticação
• No fim de 2023, foi aberto um issue dizendo que seria preciso sair do Clerk, e esse issue foi encerrado há um mês com a migração para o Better Auth
• Clerk e Supabase são serviços bem-sucedidos que levantaram, respectivamente, US$ 50 milhões em investimento e US$ 100 milhões com valuation de US$ 5 bilhões, mas a arquitetura da Val Town entrava em forte conflito com o que o Clerk pressupunha
• O processo de transição envolveu muitos contornos, bugs e incidentes, e em especial ficou claro que o principal problema era a estrutura em que o Clerk tentava substituir tanto a tabela de usuários quanto a tabela de sessões

Problema central: terceirizar a tabela de usuários e a tabela de sessões

• Por que era difícil usar o Clerk como tabela de usuários

  • O Clerk defendia fortemente a ideia de eliminar a tabela de usuários, como em seu post de 2021 “Consider dropping your users table” e no vídeo de 2023 “DELETE your Users table”
  • Na migração inicial, a Val Town achou que poderia buscar dados como configurações do usuário, URL do avatar e email na API do Clerk sempre que necessário
  • O SDK do Clerk tinha, no rootAuthLoader, a opção loadUser, que buscava dados do usuário enquanto tratava da autenticação de toda a aplicação, e isso funcionava bem em desenvolvimento
  • Em produção, o limite desse endpoint era de 5 requisições por segundo para a conta inteira, somando todos os usuários, e esse problema depois foi resolvido com a remoção da opção
  • Serviços com recursos sociais, como a Val Town, precisam mostrar em várias páginas o conteúdo, nome de usuário e avatar de outras pessoas, então a premissa da UI padrão do Clerk — em que o usuário só lê do JWT seu próprio avatar e suas configurações — não se encaixava
  • A orientação do Clerk foi sincronizar avatar e outras informações entre o Clerk e a tabela de usuários da Val Town, o que na prática dividiu a autoridade sobre os mesmos dados em dois lugares e criou a complexidade de operar duas tabelas de usuários

• A complexidade do fluxo de cadastro criada pela sincronização via webhook

  • Para sincronizar os dados do Clerk com o banco de dados da Val Town, era preciso usar webhooks, e o processo de cadastro ficou complexo e delicado
  • Logo após o cadastro, por um breve período, o usuário podia ter uma conta no Clerk, mas ainda não ter uma linha correspondente no banco de dados da Val Town
  • Como a Val Town exige nome de usuário, também era possível que o usuário ficasse num estado em que já existiam a conta no Clerk e a linha no banco, mas a conta ainda não estivesse completa
  • As configurações do usuário acabavam divididas entre itens gerenciados pelo Clerk, como métodos de autenticação, e itens de que a Val Town precisava, como nome de usuário e configurações do editor

A estrutura de sessões em que o Clerk virou ponto único de falha

• Sessões de usuário baseadas em cookie normalmente duram pouco e são renovadas continuamente, para que possam ser invalidadas rapidamente
• Nessa estrutura, a cada poucos minutos o usuário precisava trocar o cookie de sessão por um novo, e um subdomínio da Val Town encaminhava a requisição ao Clerk para processar a renovação
• A Val Town não tinha uma tabela de sessões nem assumia responsabilidade pelas sessões
• Essa abordagem é boa quando se quer evitar assumir a responsabilidade pela autenticação, mas se o Clerk cai, não são apenas login e logout que quebram: até usuários já autenticados acabam sem conseguir usar o site inteiro
• O Clerk tinha incidentes frequentes e prolongados, e, segundo a página de status desde maio de 2025, a disponibilidade percebida ficou entre 99% e 99,9%
• A confiabilidade de um sistema complexo fica limitada ao menor valor entre as confiabilidades combinadas de seus componentes importantes
• Além desses dois grandes problemas, havia outros bugs e issues relacionados ao Clerk, e embora a maioria tenha sido corrigida no fim, ainda foi preciso lidar com o “Stale Issue Bot”, que fechava issues automaticamente

Por que a troca não aconteceu imediatamente

• Fazer uma migração “de X para Y” pode prejudicar a velocidade de desenvolvimento e a estabilidade mental da equipe, então a Val Town evitava reescrever coisas a menos que fosse realmente necessário
• O Clerk oferecia SDKs para as tecnologias usadas pela Val Town, como Remix, Fastify e Express, e acompanhava relativamente bem as mudanças nesses frameworks
• Os recursos administrativos e de prevenção de abuso do Clerk ajudavam a resolver problemas de suporte ao cliente e a barrar usuários fraudulentos
• O Clerk se encaixava especialmente bem em apps relativamente simples e centrados no frontend, sem elementos sociais e sem necessidade de tabela de usuários
• Era fácil de adotar no começo, o preço era viável e o dashboard do Clerk também era bem bom
• Não havia muitas alternativas de autenticação, e entre as soluções open source várias eram antigas e praticamente abandonadas
• Plataformas de autenticação como serviço traziam risco de fornecedor, e os mesmos problemas do Clerk poderiam se repetir
• A Val Town não queria construir autenticação do zero e se expor a vulnerabilidades novas e constrangedoras, mas também não queria transferir responsabilidade demais para um fornecedor
• Em especial, passou a adotar o critério de não voltar a confiar a gestão de sessões a terceiros

Escolha do Better Auth e forma da migração

• O Better Auth atendia a muitos requisitos por ter alta qualidade de código, boa integração com vários frameworks e ser um projeto open source independente viável para uso real
• O Better Auth também continua sendo uma base de código grande e complexa desenvolvida em sua maior parte por uma única empresa, então o risco de fornecedor permanece
• Ainda assim, desaparece a dependência de um terceiro precisar permanecer online para que sessões e autenticação de usuários funcionem
• O AuthKit da WorkOS também era um forte candidato e muito bem acabado, mas depois de passar por dois fornecedores, ficou mais importante ter uma alternativa que funcionasse de forma independente e cujo núcleo fosse open source
• O dashboard e os add-ons pagos do Better Auth também atendiam às necessidades da Val Town
• A Val Town gerencia todos os dados diretamente, e um plugin expõe uma API no site da Val Town para que o dashboard do Better Auth possa buscar informações e fazer um gerenciamento leve de usuários
• O serviço pago “Infrastructure”, do Better Auth, no modo como a Val Town o usa, é na prática quase stateless e não participa da gestão de sessões
• Durante a transição, por cerca de duas semanas, a Val Town deu suporte simultâneo a Better Auth e Clerk
• Todos os endpoints que tratavam autenticação aceitavam ambos os tipos de cookie, e a página de login passou a fornecer sessões do Better Auth, permitindo que os usuários migrassem gradualmente
• Como se tratava de um trabalho relacionado à segurança, foi preciso ler, reescrever e testar todo o código com muito cuidado, e o código final de autenticação puramente com Better Auth foi todo escrito pela própria equipe
• O Better Auth também combina bem com Vals, e para adicionar autenticação ao código da Val Town é possível usar o Better Auth starter template

Lições que ficaram

• Como o tempo de atividade de um fornecedor upstream afeta diretamente o tempo de atividade do seu serviço, é preciso avaliar com cuidado o quanto você está exposto a esse risco
• Mesmo que um produto se encaixe bem em muitos casos de uso e seja muito bem-sucedido, ele pode não servir para um problema específico
• O ecossistema de software muda rápido, e uma solução adequada que não existia quando você precisava pode aparecer um ano depois

[GN⁺]

Comentários do Hacker News

• Queria que alguém mais inteligente do que eu me explicasse por que a tabela de usuários do Postgres precisa ser entregue a um provedor terceirizado
  Não entendo o que há de tão difícil em manter diretamente uma tabela numa VM da Hetzner. Não é cobrança, são só dados com alguns campos

  • Com alguns campos, sim, mas logo deixa de ser tão simples
    Entram SSO, SAML, SCIM, OIDC, OAuth, autenticação em dois fatores, autenticação sem senha, tokens de verificação, além de integrações variantes com sistemas amplamente usados para cada recurso. Na nossa empresa, por um tempo, metade do tempo dos engenheiros de suporte foi gasto lidando com todo tipo de problema de SSO do sistema de autenticação que construímos internamente
  • Eu também nunca entendi muito bem. Sempre me perguntei por que algo como o Supabase existe, e isso parece mostrar o quanto o mundo do desenvolvimento frontend se afastou de formas de construir coisas que sejam simples e seguras por padrão
  • Você não quer evoluir sua carreira para arquiteto? Desenha uma caixa, chama de User Management e conecta um SaaS como o Clerk, e pode assumir que está gerenciado
    Aí dá para empurrar para essa caixa-preta mágica todo requisito em que você sente “isso não vale a pena eu implementar”
  • As pessoas têm muito medo de errar na autenticação e serem hackeadas. Então tendem a passar essa responsabilidade para terceiros e tentar não pensar mais nisso
  • Também fico igualmente confuso. Pelo que parece, quando os requisitos não são tão amplos, é mais fácil operar o banco de dados diretamente e gerenciar a autenticação com algo como Django
    Em escala enterprise talvez seja diferente

• Aqui é o Bereket, do Better Auth. Foi exatamente para resolver esse problema que comecei o Better Auth, e depois isso virou uma empresa
  É sempre bom ver outras pessoas obtendo o mesmo valor. Ainda há muito a fazer, então gostaria de saber o que poderíamos melhorar

  • Queria saber se há planos para suporte a backend em Python. Ou se existe alguma forma de usarmos hoje
  • Você acha que a autenticação no navegador é complexa porque o navegador não faz o suficiente?

• É pior do que “a lição difícil de aprender ao construir sistemas complexos é que sua confiabilidade é igual ao mínimo da confiabilidade de seus componentes principais”
  Na prática, a disponibilidade total é o produto da disponibilidade de todos os componentes no caminho crítico. Se o software, a camada de autenticação e o provedor de nuvem têm 99% de disponibilidade cada, e se o serviço cai quando qualquer um dos três falha, a disponibilidade final é de apenas 97%. Com 11 componentes assim, não sobra nem um único “nine” na disponibilidade. Por isso é importante reduzir componentes e escolher soluções mais confiáveis, e é bom ver essa equipe seguindo esse caminho

  • Aprendi isso da pior forma durante a grande pane da Cloudflare da última vez. Eu nem usava Cloudflare, mas a chave pública do Auth0 que eu usava para validar JWT era servida por trás da Cloudflare, então toda a cadeia de autenticação quebrou e meu app ficou fora do ar por horas

• Também gostei de ler o post anterior sobre migração do Supabase (https://blog.val.town/blog/migrating-from-supabase)
  Faltam textos honestos e bons sobre decisões de engenharia de longo prazo, então espero que continuem escrevendo no blog

• Passei por algo parecido recentemente. Começamos com Stack Auth, mas por causa de limites de taxa extremamente agressivos e desempenho ruim, não dava para usar em produção, e era lento mesmo quando não batíamos no rate limit
  Depois migramos para o WorkOS AuthKit, que funciona muito melhor e também oferece recursos enterprise úteis. Ainda assim, para um projeto novo eu me sinto atraído pelo Better Auth. Sincronizar o estado do provedor de autenticação externo com o estado dos meus usuários é um foco de bugs, e ajuda manter o mínimo possível de estado no provedor, embora ainda sobre algum. Renovar tokens de acesso JWT a cada poucos minutos também é outro foco de bugs, e sinceramente isso não seria necessário se você controlasse a autenticação diretamente. O WorkOS não é uma API completa e foi construído com a suposição de um produto por conta pagante e um número fixo de ambientes (staging, production e mais um se você pedir ao suporte). Coisas como URLs de redirecionamento também precisam entrar numa lista de permissões no dashboard, e não parece haver um jeito fácil para agentes lidarem com isso. Terceirizar autenticação não faz muito sentido na minha opinião. Quanto menos você fragmenta o estado entre vários serviços, menos problemas surgem. Há casos inevitáveis, como pagamentos, ou casos em que um banco especializado é necessário por desempenho, mas para autenticação realmente não vejo motivo para isso se existe uma boa biblioteca. Dizem que com um serviço você começa mais rápido, mas os problemas que tive com serviços de autenticação não tinham relação com alta escala, e a maioria apareceu antes mesmo do lançamento

• Estou usando Clerk e estou bem insatisfeito
  Não há um RBAC decente. Os papéis ficam ligados à organização e não ao próprio usuário, então você não consegue ter algo como um administrador global, e precisa contornar isso guardando pares arbitrários de chave-valor no metadata. Também houve várias indisponibilidades nas últimas semanas e meses, e em todas elas o app inteiro falhou. Eu pensaria duas vezes antes de usar de novo no futuro

• Fico muito feliz por ter escolhido Lucia no começo. A biblioteca foi essencialmente encerrada, e substituída por documentação e pequenos utilitários sobre como gerenciar e hospedar autenticação por conta própria
  A autenticação sempre é apresentada como algo grande e assustador que você não consegue administrar sozinho, mas depois de passar uma semana aprendendo como segurança e salting básico funcionam, fiquei muito mais confiante em como tudo opera no conjunto

  • https://lucia-auth.com/
    Lembro quando eles aposentaram a biblioteca e a transformaram em material de aprendizado para implementar autenticação do zero. Foi uma excelente decisão, e tenho muito respeito pelo autor

• A comparação entre Clerk e Better Auth quase pode ser considerada injusta. Um é um serviço e o outro é uma biblioteca, então é como comparar coisas diferentes
  Todo serviço terceirizado que se integra à sua stack vira um ônus de responsabilidade, e bibliotecas também, mas em menor grau. Já passou da hora de mais serviços serem substituídos por bibliotecas, e o Better Auth mostra bem esse caminho. Gosto que seja uma biblioteca integrada ao frontend, backend e banco de dados

• Os textos do Tom sempre valem a leitura
  Alguém ainda se lembra de Auth0 e passportjs? A mudança nos serviços de autenticação nunca acaba, mas imagino que isso seja inevitável, já que os padrões também seguem mudando

  • OAuth 2.x e OIDC não mudaram tanto assim. Eu ainda uso Passport.js com Firebase