Live data from Hacker News

From Supabase to Clerk to Better Auth

blog.val.town

71–80 of 259 posts

Re: From Supabase to Clerk to Better Auth

#71
Had a similar journey recently. Started with Stack Auth, found it unusable in production due to extremely hard rate limits and bad performance even when not rate limited. Switched to WorkOS AuthKit, which works much better and supports useful enterprise features. But inclined to BetterAuth for new projects.

- Syncing external auth provider state with your user state is a bug center. It helps to keep as little state as possible in the auth provider, but there is still some. - Refreshing JWT access tokens every few minutes is another bug center and honestly there is no need to do this if you control your own auth. - WorkOS does not have a complete API. It is built on the assumption that you have one product per billing account and a fixed number of environments (staging, production, and they can give you another one if you ask support). You have to whitelist redirect and other URLs in the dashboard, and there doesn't seem to be an easy way for agents to do it.

Outsourcing auth does not make much sense IMO. The less you can split your state over multiple services the fewer problems you will have. Sometimes it is inevitable, like for payments, or if you need specialized databases for performance reasons. But for auth there is really no good reason if good libraries are available. To people who say that using a service will help you get started faster, none of the problems I hit with auth services had to do with having high scale -- most of them hit before I even launched.

Re: From Supabase to Clerk to Better Auth

#72

Earlier quoted context omitted.

It takes like an hour. So that's a quick mvp then

Social logins, email logins, password resets, multi-tenant, organizations, many to many users to organizations, etc etc. Not necessary for MVP, but can definitely be painful hacking in later if the MVP hits.

Social logins, multi-tenant and organizations are very far from table-stakes for an MVP.

Whether it's painful to put in later or not is sadly nothing that the managers and executives concern themselves with.

Re: From Supabase to Clerk to Better Auth

#73
post #4

> Some important context is that Clerk is a major success. They just raised 50 million dollars and they have lots of satisfied users. And even more users who are looking to escape. Clerk is just a mess. They are trying to cram EVERYTHING into their libraries: Web3 crap, Stripe, etc. Clerk's JS blob is now triggering the browser inspectors for being slow to load. Every time when we upgraded React, Clerk libraries were…

> And even more users who are looking to escape. Uhm, companies like Replit and several other large startups are actually adopting Clerk. I guess if your world mainly revolves around X (formerly Twitter), it can seem like everyone is moving away from Clerk. Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.

Clerk looks _really_ good initially. It's perfect if you want to prototype something and not care about auth.

It's only when you start getting into the details that you begin to suffer. For example, there's _still_ no way to do offline auth on mobile. So that your application could be opened if there's no connectivity at the moment. But hey, you can do the Metamask Web3 blockchain thingie!

I have never used Twitter/X, and I don't even have an account there. I'm purely talking about my personal experience and the experience of other companies that I know personally.

> Also, Better Auth’s X presence is pretty much centered around criticizing every auth provider out there, so the discourse there tends to skew heavily negative.

They are actually not wrong. Auth is not such a hard task, it's just a lot of drudgery that detracts you from the actual goal of your company. But it's critical functionality that MUST ALWAYS WORK, before all else. And Clerk just fails this test.

I'm switching my company to Logto (it's lightweight and when something breaks, I know how to pick up the pieces), so I don't even have an opinion on Better Auth.

Re: From Supabase to Clerk to Better Auth

#74
post #58
post #19

Hey, Bereket from Better Auth here. I started Better Auth to solve this exact issue for myself, and it later turned into a company. It always give me joy to just see others getting the same value from it :) There is a lot to work on, would love to know what we can improve

Hey hey! Qq: you guys plan to support Python backends or is there a way for us to do this?

Works fine with my fastapi backend using the JWT plugin. I run better-auth as a standalone service.

https://better-auth.com/docs/plugins/jwt

Re: From Supabase to Clerk to Better Auth

#75

Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data

You are not supposed to offload your users table, you are supposed to offload your password field.

Re: From Supabase to Clerk to Better Auth

#77
post #70

Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data

I must as intelligent as you because I also never understood why things like supabase even exist. I believe this shows how much front-end dev world is detached from how things can simple and secure by default.

Do you say the same about AWS RDS. Are you saying VMs is all you need and it is a doddle for anyone with FE only experience to set up, maintain and scale.

Re: From Supabase to Clerk to Better Auth

#78
post #48

Earlier quoted context omitted.

Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases. To expand a bit more: if a business is faced with a choice to save some…

This comment is more ridiculous than ever in 2026.

Emperor, meet clothes.

Re: From Supabase to Clerk to Better Auth

#79

Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data

I am just as confused as you. My 2c: For a broad range of requirements, running your DB directly and managing auth with Django or similar is easier. Perhaps at enterprise scale, this changes.

Re: From Supabase to Clerk to Better Auth

#80

Can someone more intelligent then me tell me why should I offload my postgres users table to some 3rd party provider? Like what is so hard about keeping that table in my VM on hetzner that I have to give it off to someone else? It's not payments, it's just a few fields of data

Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases. To expand a bit more: if a business is faced with a choice to save some…

I see Postgres etc as the builder. Supabase is more like the realtor; a middle man extracting profits and complicating the situation.
Post reply on HN