De Supabase à Clerk, puis à Better Auth

• En 2023, Val Town a quitté Supabase et a migré vers une configuration de base de données plus traditionnelle, avec la base de données sur Render et l’authentification sur Clerk. Mais cette architecture, qui externalisait la responsabilité des utilisateurs et des sessions, ne convenait pas, et l’équipe est passée à Better Auth il y a un mois
• Clerk proposait de supprimer la table des utilisateurs, mais Val Town devait souvent afficher le contenu, les noms d’utilisateur et les avatars de plusieurs utilisateurs à cause de ses fonctions sociales. Entre les limites de l’API Clerk et les besoins de synchronisation, cela a créé en pratique la complexité de gérer deux tables utilisateurs
• Comme Clerk gérait aussi le renouvellement des sessions, il est devenu un point unique de défaillance. En cas de panne de Clerk, non seulement la connexion et la déconnexion cessaient de fonctionner, mais même les utilisateurs déjà connectés pouvaient difficilement utiliser l’ensemble du site. Depuis mai 2025, la disponibilité observée via la page de statut semblait se situer entre 99 % et 99,9 %
• Val Town n’a pas tout réécrit immédiatement, car le SDK de Clerk, ses fonctions d’administration, sa prévention des abus et son tableau de bord restaient utiles. Mais l’équipe a fixé une règle : ne plus jamais confier à un tiers la gestion des sessions
• Better Auth répondait aux besoins par la qualité de son code, son intégration aux frameworks et son noyau open source indépendant. Pendant environ deux semaines, Val Town a pris en charge Clerk et Better Auth en parallèle, en acceptant deux types de cookies pour effectuer une migration progressive des sessions

---

Contexte de la transition

• En 2023, Val Town a quitté Supabase pour passer à une architecture de base de données plus traditionnelle, remplaçant la base de données par Render et l’authentification par Clerk
• Fin 2023, un ticket avait déjà été ouvert indiquant qu’il fallait quitter Clerk, et ce ticket a été fermé il y a un mois lors de la migration vers Better Auth
• Clerk et Supabase sont des services à succès ayant respectivement levé 50 millions de dollars et 100 millions de dollars sur une valorisation de 5 milliards, mais l’architecture de Val Town entrait fortement en conflit avec les hypothèses de Clerk
• La transition a nécessité de nombreux contournements, bugs et interruptions, et le principal problème est apparu clairement : Clerk voulait remplacer à la fois la table des utilisateurs et la table des sessions

Problème central : l’externalisation des tables utilisateurs et sessions

• Pourquoi Clerk ne convenait pas comme table utilisateurs

  • Clerk recommandait fortement de supprimer la table des utilisateurs, comme dans son article de 2021 “Consider dropping your users table” et sa vidéo de 2023 “DELETE your Users table”
  • Lors de la migration initiale, Val Town pensait pouvoir récupérer à la demande depuis l’API Clerk des données comme les préférences utilisateur, les URL d’avatar ou les e-mails
  • Le SDK Clerk incluait dans rootAuthLoader une option loadUser permettant de demander les données utilisateur tout en gérant l’authentification de toute l’application, et cela fonctionnait bien en environnement de développement
  • En production, la limite de cet endpoint était de 5 requêtes par seconde pour l’ensemble du compte, tous utilisateurs confondus, problème qui a ensuite été résolu par la suppression de l’option
  • Pour un service avec des fonctions sociales comme Val Town, il faut afficher sur de nombreuses pages le contenu, les noms d’utilisateur et les avatars d’autres utilisateurs, ce qui ne correspondait pas à l’hypothèse d’interface par défaut de Clerk, où l’utilisateur lit surtout son propre avatar et ses propres préférences depuis le JWT
  • Le conseil de Clerk était de synchroniser les avatars et autres informations entre Clerk et la table utilisateurs de Val Town, ce qui revenait à répartir l’autorité sur les mêmes données à deux endroits et créait la complexité de gérer deux tables utilisateurs

• La synchronisation par webhook a compliqué le flux d’inscription

  • Pour synchroniser les données Clerk vers la base de données de Val Town, il fallait utiliser des webhooks, ce qui rendait le processus d’inscription complexe et fragile
  • Juste après l’inscription, un utilisateur pouvait se retrouver pendant un court moment avec un compte Clerk mais sans ligne correspondante dans la base de données de Val Town
  • Comme le nom d’utilisateur est obligatoire chez Val Town, un utilisateur pouvait aussi se retrouver avec un compte Clerk et une ligne en base, mais avec un compte encore incomplet
  • Les préférences utilisateur devaient être séparées entre ce que Clerk gérait, comme la méthode d’authentification, et ce dont Val Town avait besoin, comme le nom d’utilisateur ou les préférences de l’éditeur

Une architecture de session où Clerk est devenu un point unique de défaillance

• Les sessions utilisateur basées sur des cookies sont généralement de courte durée et continuellement renouvelées, afin de pouvoir être invalidées rapidement
• Dans cette architecture, l’utilisateur devait toutes les quelques minutes échanger son cookie de session contre un nouveau, les sous-domaines de Val Town relayant la requête vers Clerk pour gérer ce renouvellement
• Val Town n’avait pas de table des sessions et n’en assumait pas non plus la responsabilité
• Cette approche est pratique si l’on veut éviter la responsabilité de l’authentification, mais lorsque Clerk tombe en panne, ce ne sont pas seulement la connexion et la déconnexion qui cassent : même les utilisateurs déjà connectés peuvent se retrouver dans l’impossibilité d’utiliser tout le site
• Clerk a connu des pannes fréquentes et longues, et d’après la page de statut depuis mai 2025, la disponibilité observée semblait se situer entre 99 % et 99,9 %
• La fiabilité d’un système complexe est contrainte par le minimum des fiabilités combinées de ses composants critiques
• Au-delà de ces deux grands problèmes, il y a aussi eu d’autres bugs et problèmes liés à Clerk, dont la plupart ont fini par être corrigés, mais il a fallu se battre avec le “Stale Issue Bot”, qui fermait automatiquement les tickets

Pourquoi la migration n’a pas eu lieu plus tôt

• Un travail de type “passer de X à Y” peut nuire à la vitesse de développement et à la stabilité mentale de l’équipe, donc Val Town évitait de réécrire sauf en cas de nécessité absolue
• Clerk fournissait des SDK pour les technologies utilisées par Val Town, comme Remix, Fastify et Express, et suivait plutôt bien l’évolution de ces frameworks
• Les fonctions d’administration et de prévention des abus de Clerk ont aidé à résoudre des problèmes de support client et à bloquer les utilisateurs frauduleux
• Le cas d’usage où Clerk était particulièrement adapté concernait les applications front-end relativement simples, sans dimension sociale et sans besoin de table utilisateurs
• Il était facile de démarrer, le prix restait supportable, et le tableau de bord de Clerk était plutôt bon
• Les alternatives en matière d’authentification étaient peu nombreuses, et parmi les solutions open source, beaucoup étaient anciennes et de fait abandonnées
• Les plateformes d’authentification en tant que service comportaient un risque fournisseur, avec la possibilité de revoir se reproduire les mêmes problèmes qu’avec Clerk
• Val Town ne voulait pas reconstruire toute l’authentification depuis zéro et s’exposer à de nouvelles vulnérabilités embarrassantes, mais ne voulait pas non plus transférer trop de responsabilités à un fournisseur
• En particulier, l’équipe s’est fixé comme règle de ne plus jamais faire confiance à un tiers pour la gestion des sessions

Choix de Better Auth et méthode de migration

• Better Auth remplissait de nombreuses conditions : haute qualité de code, bonne intégration à plusieurs frameworks, et viabilité réelle en tant que projet open source indépendant
• Better Auth reste toutefois une base de code vaste et complexe développée en grande partie par une seule entreprise, donc le risque fournisseur n’a pas complètement disparu
• En revanche, il n’existe plus de dépendance à un tiers qui doive rester en ligne en permanence pour que les sessions et l’authentification des utilisateurs fonctionnent
• AuthKit de WorkOS était aussi un candidat solide et très fluide, mais après être déjà passé par deux fournisseurs, il est devenu important d’avoir une alternative fonctionnant de manière indépendante, avec un noyau open source
• Le tableau de bord de Better Auth et ses extensions payantes correspondaient aussi aux besoins de Val Town
• Val Town gère désormais toutes les données directement, et un plugin expose une API sur le site de Val Town afin que le tableau de bord Better Auth puisse récupérer des informations et effectuer une gestion légère des utilisateurs
• Le service payant “Infrastructure” de Better Auth est, dans l’usage qu’en fait Val Town, quasiment sans état et n’intervient pas dans la gestion des sessions
• Pendant la période de transition, Val Town a pris en charge Better Auth et Clerk simultanément pendant environ deux semaines
• Tous les endpoints traitant l’authentification acceptaient les deux types de cookies, et la page de connexion fournissait des sessions Better Auth, permettant aux utilisateurs de migrer progressivement vers Better Auth
• Comme il s’agissait d’un travail lié à la sécurité, tout le code a dû être lu attentivement, réécrit et testé, et le code final d’authentification pure Better Auth a été entièrement écrit en interne
• Better Auth s’intègre aussi bien avec Vals. Pour ajouter l’authentification au code Val Town, il est possible d’utiliser le starter template Better Auth

Enseignements restants

• Le temps de disponibilité des fournisseurs upstream a un impact direct sur celui du service, il faut donc évaluer avec soin à quel point on est exposé à ce risque
• Même si un produit convient à de nombreux cas d’usage et connaît un grand succès, il peut ne pas être adapté à un problème spécifique
• L’écosystème logiciel évolue rapidement, et une solution adaptée qui n’existait pas au moment voulu peut apparaître un an plus tard

[GN⁺]

Commentaires sur Hacker News

• J’aimerais que quelqu’un de plus intelligent que moi m’explique pourquoi il faudrait confier la table users de Postgres à un fournisseur tiers
  Je ne vois pas ce qu’il y a de si difficile à maintenir directement une table sur une VM Hetzner. Ce n’est pas de la facturation, juste des données avec quelques champs

  • Quand il ne s’agit que de quelques champs, oui, mais ça cesse vite d’être aussi simple
    Il faut ajouter SSO, SAML, SCIM, OIDC, OAuth, authentification à deux facteurs, authentification sans mot de passe, jetons de vérification, etc. Et pour chaque fonctionnalité, on demande aussi des intégrations variées avec des systèmes courants. Dans notre entreprise, pendant un temps, la moitié du temps de nos ingénieurs support passait à gérer toutes sortes de problèmes SSO liés à notre système d’authentification maison
  • J’ai du mal à comprendre moi aussi. Je me suis toujours demandé pourquoi quelque chose comme Supabase existait, et ça montre à quel point le monde du développement frontend s’est éloigné d’une manière fondamentalement simple et sûre de construire des choses
  • Tu ne veux pas faire évoluer ta carrière vers l’architecture ? Tu dessines une boîte, tu écris User Management dessus, puis tu branches un SaaS comme Clerk et tu pars du principe que c’est géré
    Comme ça, toutes les exigences pour lesquelles tu te dis « ça n’a aucune valeur que je l’implémente moi-même » peuvent être repoussées dans cette boîte noire magique
  • Les gens ont très peur de rater leur auth et de se faire pirater. Du coup, ils ont tendance à transférer cette responsabilité à un tiers et à ne plus y penser
  • Je suis tout aussi perplexe. À vue de nez, tant que les besoins restent dans un périmètre pas trop large, il est plus simple d’exploiter soi-même la base de données et de gérer l’auth avec quelque chose comme Django
    À l’échelle enterprise, c’est peut-être différent

• Je suis Bereket de Better Auth. J’ai justement lancé Better Auth pour résoudre exactement ce problème, et c’est ensuite devenu une entreprise
  C’est toujours un plaisir de voir d’autres personnes y trouver la même valeur. Il reste encore beaucoup à faire, donc j’aimerais savoir ce qu’on pourrait améliorer

  • Je me demande s’il y a un projet de support pour les backends Python, ou s’il existe déjà une manière de l’utiliser
  • Pensez-vous que l’auth est compliquée dans le navigateur parce que le navigateur n’en fait pas assez ?

• C’est pire que de dire : « la leçon difficile qu’on apprend en construisant des systèmes complexes, c’est que leur fiabilité est égale au minimum de la fiabilité de leurs composants critiques »
  En réalité, la disponibilité globale est le produit des disponibilités de tous les composants sur le chemin critique. Si le logiciel, la couche d’auth et le fournisseur cloud ont chacun 99 % de disponibilité, et que le service tombe dès qu’un seul des trois tombe, alors la disponibilité finale n’est plus que de 97 %. Avec 11 composants de ce type, il ne reste même plus un seul “nine” de disponibilité. D’où l’importance de réduire le nombre de composants et de choisir des solutions plus fiables, et c’est bien que cette équipe ait pris cette direction

  • J’ai appris ça à mes dépens lors de la dernière grosse panne de Cloudflare. Je n’utilisais même pas Cloudflare, mais les clés publiques Auth0 utilisées pour vérifier les JWT étaient servies derrière Cloudflare, donc toute la chaîne d’auth s’est cassée et l’application est restée indisponible pendant plusieurs heures

• J’ai aussi lu avec intérêt l’ancien billet sur la migration depuis Supabase (https://blog.val.town/blog/migrating-from-supabase)
  Il y a trop peu de textes honnêtes et de qualité sur les décisions d’ingénierie à long terme, donc j’espère que vous continuerez à écrire sur le blog

• J’ai vécu récemment un parcours similaire. J’ai commencé avec Stack Auth, mais à cause de limites de débit extrêmement agressives et de mauvaises performances, c’était inutilisable en production, et c’était lent même sans atteindre les limites
  Je suis ensuite passé à WorkOS AuthKit, qui fonctionne bien mieux et prend aussi en charge des fonctionnalités enterprise utiles. Malgré tout, pour un nouveau projet, je serais tenté par Better Auth. Synchroniser l’état entre un fournisseur d’auth externe et l’état de mes utilisateurs est un nid à bugs, et garder le moins d’état possible chez le fournisseur aide, mais il en reste quand même un peu. Le fait de rafraîchir des jetons d’accès JWT toutes les quelques minutes est aussi un autre nid à bugs, et si on contrôle soi-même son auth, franchement, ce n’est pas nécessaire. WorkOS n’a pas une API complète, et il a été conçu avec l’hypothèse d’un seul produit par compte de facturation et d’un nombre fixe d’environnements (staging, production, et un de plus sur demande au support). Des choses comme les URL de redirection doivent aussi être ajoutées à une liste autorisée dans le dashboard, et il ne semble pas y avoir de moyen simple pour qu’un agent le gère facilement. Externaliser l’auth n’a pas beaucoup de sens à mes yeux. Moins on fragmente l’état entre plusieurs services, moins on a de problèmes. Il y a des cas inévitables, comme la facturation, ou des besoins de bases de données spécialisées pour des raisons de performances, mais pour l’auth, s’il existe une bonne bibliothèque, il n’y a vraiment pas de raison. On dit aussi qu’un service permet de démarrer plus vite, mais les problèmes que j’ai eus avec des services d’auth n’avaient rien à voir avec la grande échelle et surgissaient pour la plupart avant même le lancement

• J’utilise Clerk et j’en suis assez mécontent. Il n’y a pas de vrai RBAC
  Les rôles sont liés à l’organisation et non à l’utilisateur lui-même, donc on ne peut pas avoir un concept comme celui d’administrateur global, et il faut contourner ça en stockant des paires clé-valeur arbitraires dans les metadata. Il y a aussi eu plusieurs indisponibilités ces dernières semaines et ces derniers mois, et à chaque fois c’est toute l’application qui tombait. Je réfléchirais à deux fois avant de le réutiliser

• Je suis vraiment content d’avoir choisi Lucia très tôt. La bibliothèque est en pratique abandonnée, et elle a été remplacée par de la documentation et de petits utilitaires expliquant comment gérer et héberger soi-même son auth
  L’auth est toujours présentée comme quelque chose de vaste et d’effrayant qu’on ne peut pas gérer soi-même, mais après avoir passé environ une semaine à apprendre comment fonctionnent la sécurité et le salage de base, j’ai eu beaucoup plus confiance dans la compréhension de tout le fonctionnement

  • https://lucia-auth.com/
    Je me souviens du moment où ils ont abandonné la bibliothèque pour en faire une ressource pédagogique sur l’implémentation de l’auth depuis zéro. C’était une excellente décision, et j’ai énormément de respect pour l’auteur

• On pourrait presque dire que la comparaison entre Clerk et Better Auth est injuste. L’un est un service, l’autre une bibliothèque, donc c’est comparer des pommes et des oranges
  Tout service tiers intégré à une stack devient une responsabilité supplémentaire, et une bibliothèque aussi, mais dans une moindre mesure. Il est temps que davantage de services soient remplacés par des bibliothèques, et Better Auth montre bien cette approche. J’aime que ce soit une bibliothèque intégrée au frontend, au backend et à la base de données

• Les articles de Tom valent toujours la lecture
  Est-ce que quelqu’un se souvient encore de Auth0 et de passportjs ? Les services d’auth ne cessent d’évoluer, mais les standards aussi, donc j’imagine que c’est inévitable

  • OAuth 2.x et OIDC n’ont pas tellement changé. J’utilise encore Passport.js avec Firebase