My biggest question, that I didn’t see answered, is how the transition comes to an end. If creds aren’t in your system, how well do they transfer? Does it require user involvement? What if they don’t fast enough? What about complex integrations like SSO, SCIM, and passkeys (which are domain scoped)?
From Supabase to Clerk to Better Auth
111–120 of 259 posts
Re: From Supabase to Clerk to Better Auth
#112Can 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
It’s just a few fields until it’s not. SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec. For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
Is this perhaps a reason to have a Users table that is separate from the table of data on how you authenticate that user?
Re: From Supabase to Clerk to Better Auth
#113Earlier quoted context omitted.
Or I could use a web framework that offers that out of the box, and its free and lives in my database, wherever I want.
I use better auth for a side project i'm working on. It's open source, you can pay them to manage your user/auth tables if you want or you can run it all on your own db.
Sure, I guess if I'm using a web framework that is not quite batteries included, that makes sense, but Django, ASP .NET Core, Ruby on Rails, and so many others are open source and have authentication / users / roles baked in out of the box.
Re: From Supabase to Clerk to Better Auth
#114> 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.
Replit is using Clerk to power their login?
Re: From Supabase to Clerk to Better Auth
#115Can 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
People are very scared of messing up authentication and getting hacked. They would rather offload that responsibility to a third party and not think about it.
Unfortunately this is a common premise and on surface its a good idea too to let a expert in particular domain handle it. Where it gets muddy is when this third party are themselves learners and just see this as a good business opportunity
Re: From Supabase to Clerk to Better Auth
#116Can 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
The only project where this was the case that I didn't hate it was at a former employer, and it gave the responsibility of securing users to Auth0 and minimized our PII and attack surface, since even the login page was not hosted or controlled by us. Worse case you somehow hacked our users and got some free entree reward they had, otherwise good luck trying to get very little data.
It allowed us to do SSO for small one-off marketing / campaign focused sites. I could give a specific login URL and it would always log you in if you were already logged on.
Re: From Supabase to Clerk to Better Auth
#117Earlier quoted context omitted.
It’s just a few fields until it’s not. SSO, SAML, SCIM, OIDC, OAuth, 2FA, passwordless auth, verification tokens, etc etc, And, variations of each for wildly popular systems you’ll be expected to integrate with but don’t support the exact spec. For a while at my company, half our support engineers time went to handling random SSO issues that came up in our home built auth system.
Majority of apps are B2C apps, they don't need any of this. All you need is Apple and Google Oauth.
If you are just starting out its probably a good idea. Think about the use case when google bans either your app or bans your app user?
Re: From Supabase to Clerk to Better Auth
#118Never outsource your auth no matter what unless you're vibe coding and it doesn't matter. If that's the case, don't put auth in at all because it's just you anyway or just use vibe coded password lookups from database at that point.
Lastly - here's the law of mother nature:
Software funded by VCs will milk you and will milk you dry. Not now, not tomorrow maybe decade or two later when the hot potato being passed around reaches to the last party holding the bag that now needs its money back with all that others had their 10x returns already taken from them by soldng them at an inflated price to the last party holding the bag.
Clerk's pricing should be evidence enough.
Re: From Supabase to Clerk to Better Auth
#119I'm surprised to see so many top comments here promoting building your own auth. For years I've only heard "never roll your own auth."
Re: From Supabase to Clerk to Better Auth
#120Can 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
People are afraid to touch dangerous things, like passwords and payment systems. Depending on their skill level, they should indeed be afraid.