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
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.
What you are talking about is in a large part authentication. You can do authentication using an external service and still have your user table locally. You can also do authorization locally with a local session table while leaving authentication to a SaaS.
Don't you wanna level up your career to become an architect? You can draw a box, call it "User Management" and slap "Clerk" or some other SaaS on it, and assume it's managed for you. This allows you to shove whatever requirements you want in that magic blackbox as you feel "it doesn't bring value" for you to implement.
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 money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.
> Okay, so… what are those cases? I’m also curious.
If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.
If you're not threatened by per-user-per-month fees, you can delegate auth.
If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)
If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.
If you’re implying that people should __always__ roll their own services and never vendor out non-core parts, the security industry would love to learn where you work.
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.
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.
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.
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.
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
I think auth is complicated outside of browsers too. But browsers do make some things uniquely confusing, especially cookies and general security primitives are full of footguns
I enjoyed the Supabase migration article from a while ago (https://blog.val.town/blog/migrating-from-supabase) as well. There's a shortage of good, honest writing on long-term engineering decisions, please keep up the blog!
> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.
It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.
That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.
Learned this one the hard way during the last major CloudFlare outage. I don't use them, but their outage bricked my app for hours anyway because the Auth0 public keys used to verify JWTs were served behind CloudFlare, breaking the entire auth chain. Fun!
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.
Using Clerk, quite unhappy with it. No proper RBAC (roles are tied to organizations, not stored on user itself, so you cannot have a concept of global admin or something like that, unless you use metadata for storing arbitrary key value paris), and more than once in the past weeks/months it had a downtime causing the whole app to fail.
This is why I'm so thankful I went with Lucia early. They sort of sunset their library and replaced it with documentation (and some small utilities) for how to manage and host authentication for yourself. It's always presented as some big, scary thing you can't manage yourself, but I found that taking the week to learn how security and basic salting works, I was able to feel more confident about how everything worked.
I remember when they deprecated the library and instead made it a learning resource on implementing auth from scratch. Brilliant decision, much respect to the author.
You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.
If anything I feel like Clerk adoption is becoming the norm in recent years. I started using it about a year ago and found it to have troublesome reliability.
Does Better Auth still have the weird design to be everything “request header based”? I remember running admin scripts and tests to be very hacky due to it cause if you skipped that plugins wouldn’t run
Better auth is great! I love how it's way more hackable than using a something like Clerk. We were able to add a plugin to allow auth via iframe postMessage (embedded in a CRM) and everything worked seamlessly.
Lol wut? you get all of your auth data in your own db in 1 cli command. You are not tied to any on db provider. On top of that you get hundreds of auth features like oauth providers (I use it to allow users to log in via google, apple, github) and the best part it's free. Not saying Supabase and Clerk are bad, but they cost money. With better auth you pay exactly $0 for all of this.
I remember Laravel with Socialite [0]. Laravel is what I usually reach for Web SaaS MVP. You only need a VPS and a managed database for testing out the market and can scale a lot without increasing expenses that much..
Lol, I developed for entrepreneurs who mostly wanted a working proof of concept of their ideas. I guess now you can vibecode them with SaaS for core technical needs.
I’ve looked at these auth providers many times over the years and I just don’t get the value. It takes me a couple of minutes to set up auth. Why would I want a dependency? It doesn’t help me with the hardest part which is configuring Google and Apple sign in stuff on Google and Apple. I just don’t get it.
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.
> 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 the biggest pain with their transitive dependencies. We had issues with Stripe libraries with conflicting versions, etc.
And forget about debugging it. The libraries are obfuscated, and the TS code is impenetrable mess of abstractions to support "isomorphic" code that can run transparently on the frontend and backend.
And their platform itself is lacking important functionality, like freaking audit logs and versioning. Somebody (probably) accidentally changed a setting in their console, and we couldn't trace back when it happened or who did it.
Edit: oh yeah, and don't forget their unreliability. I had to wake up on Sunday to deal with Clerk failing the API calls for token refreshes last week.
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.
Has anyone used Keycloak for actual production? I have often thought about it but I stick to Auth0 just because I don't know if Keycloak has a good track record?
That's a good question, I was having a hard time figuring that out myself. They call themselves the "zapier" for developers. In reality it seems kinda like a FaaS but idk. They have a code intelligence product that seems like a FIM autocomplete. Very confusing product suite.
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
Start any greenfield project, hand-coded auth takes up 50% of the development time of the entire MVP
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.
What you are talking about is in a large part authentication. You can do authentication using an external service and still have your user table locally. You can also do authorization locally with a local session table while leaving authentication to a SaaS.
By the time you're so big you need all of that, there will be other people at the table to "hack that in".
I strongly disagree. If you’re selling to other businesses, much of that is an expectation.
All I am seeing here is Django modules
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.
Django, Rails etc handles this.
…use Django, install auth modules
BetterAuth is users in your own database. So you don’t have to!
Don't you wanna level up your career to become an architect? You can draw a box, call it "User Management" and slap "Clerk" or some other SaaS on it, and assume it's managed for you. This allows you to shove whatever requirements you want in that magic blackbox as you feel "it doesn't bring value" for you to implement.
AuthN is hard and generic, authZ is easy and specific. Offload authN, and keep your users table in your Hetzner.
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 money by increasing risk, having people who’s job it isn’t managing and supposedly securing that information, or to have a third-party who job is literally to handle and worry about those things, who carries independent insurance, and who is on the hook if they lose customer data, and in exchange the business is simply taking the risk of associating with business that could do a poor job — which of those options sounds more appealing from a business sense? It’s a lot easier to blame someone else than earn back trust for your own major mistakes because you tried to write your own software to save a little money.
That’s the SaaS value proposition.
>that doesn’t mean it’s the best use of your time in all cases
Okay, so… what are those cases? I’m also curious.
> Okay, so… what are those cases? I’m also curious.
If you're willing to make a third party SaaS's uptime the ceiling for your own org, you can delegate auth. Github might not be a good choice for SSO.
If you're not threatened by per-user-per-month fees, you can delegate auth.
If your threat model is compatible with a third party having visibility into your user's network location and the frequency and duration of their activities across your org, you can delegate auth. (Okta will probably not inform your competitor that your main sales guy is in North Carolina this week and has logged in from the conference room wifi of your competitor's main client.)
If you can trust the third party to not allow an interloper to bypass your requirements, you can delegate auth.
This comment is more ridiculous than ever in 2026.
Yes the analogy doesn't work here because that is much more cost prohibitive and labor intensive.
Because of AI or because hackers are hyper targeting infra clusters?
Emperor, meet clothes.
If you’re implying that people should __always__ roll their own services and never vendor out non-core parts, the security industry would love to learn where you work.
I see Postgres etc as the builder. Supabase is more like the realtor; a middle man extracting profits and complicating the situation.
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.
"home built auth system" is bound to have "random SSO issues". You fix them, that's how things mature.
I'm guessing they simply didnt want to spend the time and money doing that
Majority of apps are B2C apps, they don't need any of this.
All you need is Apple and Google Oauth.
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.
You are not supposed to offload your users table, you are supposed to offload your password field.
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.
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.
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
Do you think the complexity of auth in the browser, is because browsers don't do enough?
I think auth is complicated outside of browsers too. But browsers do make some things uniquely confusing, especially cookies and general security primitives are full of footguns
Not who you're replying to but browsers do way too much. Load the code you're given and don't do anything else.
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
I enjoyed the Supabase migration article from a while ago (https://blog.val.town/blog/migrating-from-supabase) as well. There's a shortage of good, honest writing on long-term engineering decisions, please keep up the blog!
> A hard lesson you learn building a complex system is that its reliability is the minimum of the combined reliability of its critical parts.
It's worse than that, the combined availability is the product of all components in the critical path. If your software, the authentication layer, and the cloud provider each have 99% availability, and any one of them can bring your service down, then your final availability is just 97%. With eleven components like that you have zero nines of availability.
That's why reducing components and going for reliable solutions is so important. I'm happy that the team took this path.
Learned this one the hard way during the last major CloudFlare outage. I don't use them, but their outage bricked my app for hours anyway because the Auth0 public keys used to verify JWTs were served behind CloudFlare, breaking the entire auth chain. Fun!
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.
Using Clerk, quite unhappy with it. No proper RBAC (roles are tied to organizations, not stored on user itself, so you cannot have a concept of global admin or something like that, unless you use metadata for storing arbitrary key value paris), and more than once in the past weeks/months it had a downtime causing the whole app to fail.
Would think twice before using it in the future.
This is why I'm so thankful I went with Lucia early. They sort of sunset their library and replaced it with documentation (and some small utilities) for how to manage and host authentication for yourself. It's always presented as some big, scary thing you can't manage yourself, but I found that taking the week to learn how security and basic salting works, I was able to feel more confident about how everything worked.
https://lucia-auth.com/
I remember when they deprecated the library and instead made it a learning resource on implementing auth from scratch. Brilliant decision, much respect to the author.
You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.
Tom's articles are always a good read.
Anyone remember Auth0 and passportjs?
The churn of auth services is never ending, but I suppose so are the standards.
OAuth 2.x and OIDC haven’t changed much. I still use Passport.js with Firebase.
If anything I feel like Clerk adoption is becoming the norm in recent years. I started using it about a year ago and found it to have troublesome reliability.
Does Better Auth still have the weird design to be everything “request header based”? I remember running admin scripts and tests to be very hacky due to it cause if you skipped that plugins wouldn’t run
Better auth is great! I love how it's way more hackable than using a something like Clerk. We were able to add a plugin to allow auth via iframe postMessage (embedded in a CRM) and everything worked seamlessly.
what do you get from Better Auth btw? When I used it last year, I still found it lacking and it seemed to be run by one guy.
Lol wut? you get all of your auth data in your own db in 1 cli command. You are not tied to any on db provider. On top of that you get hundreds of auth features like oauth providers (I use it to allow users to log in via google, apple, github) and the best part it's free. Not saying Supabase and Clerk are bad, but they cost money. With better auth you pay exactly $0 for all of this.
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.
this is sorta the obvious takeaway here. as a postgres/phoenix/elixir enjoyer i am blissfully unaware of all this sort of SaaS churn.
What framework offers all those auth features OOTB?
Laravel
https://laravel.com/docs/13.x/authentication
https://laravel.com/docs/13.x/socialite
https://laravel.com/docs/13.x/sanctum
ASP .NET Core, Ruby on Rails, Django, .... the list goes on and on... The ones that don't usually someone built a package that lets it happen.
I remember Laravel with Socialite [0]. Laravel is what I usually reach for Web SaaS MVP. You only need a VPS and a managed database for testing out the market and can scale a lot without increasing expenses that much..
[0]: https://laravel.com/docs/13.x/socialite
Take this post down immediately ! /jk
Lol, I developed for entrepreneurs who mostly wanted a working proof of concept of their ideas. I guess now you can vibecode them with SaaS for core technical needs.
I’ve looked at these auth providers many times over the years and I just don’t get the value. It takes me a couple of minutes to set up auth. Why would I want a dependency? It doesn’t help me with the hardest part which is configuring Google and Apple sign in stuff on Google and Apple. I just don’t get it.
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.
It must have come a long way then -- I'm integrating it into a new product and it is absolutely fantastic. It just works.
> 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 the biggest pain with their transitive dependencies. We had issues with Stripe libraries with conflicting versions, etc.
And forget about debugging it. The libraries are obfuscated, and the TS code is impenetrable mess of abstractions to support "isomorphic" code that can run transparently on the frontend and backend.
And their platform itself is lacking important functionality, like freaking audit logs and versioning. Somebody (probably) accidentally changed a setting in their console, and we couldn't trace back when it happened or who did it.
Edit: oh yeah, and don't forget their unreliability. I had to wake up on Sunday to deal with Clerk failing the API calls for token refreshes last week.
> 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.
in rails I just authentication-zero.
no need for 3rd party provider.
This is what I use, great little library and haven’t touched nor thought about my auth since I set it up.
Has anyone used Keycloak for actual production? I have often thought about it but I stick to Auth0 just because I don't know if Keycloak has a good track record?
For what it's worth Authentik has been listing Cloudflare as a customer for a while. Worth a look. There might be something in their blog.
If you're in Elixir-land, I've put together a few packages to help migrating from Supabase (or other stacks):
- https://github.com/agoodway/introspex (generate Ecto Schemas from postgres tables)
- https://github.com/agoodway/pgrest (Supabase/PostgREST compatible query engine)
I also found this helpful in the migration: https://github.com/supabase-community/supabase-ex
Nothing for auth, I basically did a one-off script for that. Phoenix auth stuff that comes out of the box is great.
Oh, and http://github.com/agoodway/walex if you need the realtime database change stuff.
I've just stuck with Auth0 for years now.
Easy to use and high reliability. Some of these other providers are not the best at reliability.
The homepage of val.town says "Zapier for know-code engineers".. Is KNOW-code engineer a term?
It's just a play on the phrase "no code".
Maybe you can help me out: I still have no idea what val.town is. I guess it's an alternative to Cloudflare Workers?
That's a good question, I was having a hard time figuring that out myself. They call themselves the "zapier" for developers. In reality it seems kinda like a FaaS but idk. They have a code intelligence product that seems like a FIM autocomplete. Very confusing product suite.