7 ms·
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 ta
by tornikeo 5mo ago
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
- mvkel 5mo agoStart any greenfield project, hand-coded auth takes up 50% of the development time of the entire MVP
- awestroke 5mo agoIt takes like an hour. So that's a quick mvp then
- transitorykris 5mo agoSocial 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.
- koliber 5mo agoWhat 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.
- RedShift1 5mo agoBy the time you're so big you need all of that, there will be other people at the table to "hack that in".
- SkyPuncher 5mo agoI strongly disagree. If you’re selling to other businesses, much of that is an expectation.
- xmcp123 5mo agoAll I am seeing here is Django modules
- pdimitar 5mo agoSocial 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.
- Orygin 5mo agoDepends on the company and product. The SSO/Social login, multi tenant and multi platform are indeed needed for my MVP.
- pdimitar 5mo agoIndeed it depends of course. Though I don't find it fair for those requirements to be presented as table-stakes and required, as my original parent comment seems to have done.
- the__alchemist 5mo agoDjango, Rails etc handles this.
- mvkel 5mo agoSo... you just have to not build your web app in the most popular web app language? Somehow i think there will be big time debt from that decision
- the__alchemist 5mo agoThose are both very popular languages for web backends, and both of those platforms are mature and robust.
- xmcp123 5mo agoNot as big as the debt you will get from having to implement it all yourself. And it's not like he's suggesting you use cobol - there is not an issue of finding people who can work with both rails and django, so the popularity isn't really relevant.
- nimchimpsky 5mo ago[dead]
- xmcp123 5mo ago…use Django, install auth modules
- deleted 5mo ago[deleted]
- jadbox 5mo agoI feel seen. It's compounded if you also need to add HIPAA row-level security compliance that spans to every form of resource.
- deleted 5mo ago[deleted]
- princevegeta89 5mo agoI would disagree here. You probably need OAuth with popular social services and implement username, password or OTP-based auth overall. For an MVP, you don't need to care about more details beyond this; it is hardly 10% of the entire effort, if not 5%.
- cpursley 5mo agoMature frameworks generally handle auth out of the box.
- oompydoompy74 5mo agoBetterAuth is users in your own database. So you don’t have to!
- tornikeo 5mo agoWhy better auth and not, postgres in docker? What is it better about better auth compared to the ol reliable postgres?
- oompydoompy74 5mo agoI think you are misunderstanding. Better Auth just uses your existing database… It’s just a library.
- eddythompson80 5mo agoDon'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.
- normie3000 5mo agoAuthN is hard and generic, authZ is easy and specific. Offload authN, and keep your users table in your Hetzner.
- therealpygon 5mo agoWhy 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.
- notatoad 5mo ago>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.
- elevation 5mo ago> 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.
- pietz 5mo agoThis comment is more ridiculous than ever in 2026.
- SkyPuncher 5mo agoIt’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.
- jarym 5mo ago"home built auth system" is bound to have "random SSO issues". You fix them, that's how things mature.
- rubogubo 5mo agoI'm guessing they simply didnt want to spend the time and money doing that
- janderson215 5mo agoPossibly didn’t want to accept the additional risk that comes with rolling your own auth as well.
- SkyPuncher 5mo agoYep, it’s just a drag. It’s not our core product value so any effort we put into it is a drag.
- ButyTh0 5mo agoRather than just use an email solution Google built GMail into a massive email solution despite it not being a core product Sometimes that's just an opportunity
- jdmichal 5mo ago> ... not being a core product Technically true, because Google's core product is ads. Also fundamentally wrong, because Gmail serves as a massive source of ad targeting information, in addition to being a high-engagement canvas to display those ads.
- jarek83 5mo agoI 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.
- dnnddidiej 5mo agoDo 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.
- kevmo314 5mo agoYes many people do say the same about AWS RDS.
- f3408fh 5mo agoYeah you’re a bit confused. Supabase has nothing to do with frontend other than providing SDKs and some frontend components to integrate with their backend.
- pbalau 5mo agoYou are not supposed to offload your users table, you are supposed to offload your password field.
- the__alchemist 5mo agoI 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.
- throwaway613746 5mo ago[dead]
- jonas21 5mo agoThat's what they did. They migrated to Better Auth, which stores everything in your DB. It's the equivalent of Django auth for the Typescript ecosystem.
- il 5mo agoPeople 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.
- sandeepkd 5mo agoUnfortunately 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
- mooreds 5mo agoI wrote an article about this: https://ciamweekly.substack.com/p/ciam-for-the-single-application https://ciamweekly.substack.com/p/ciam-for-the-single-applic... The tl;dr of the article is that there are auth specific features that are not differentiated but that users expect. Just like you might outsource pieces of functionality like data storage and message sending to specialized servers/libraries/applications, you can do the same with authentication. The article could use some improvements, tbh, it is 2.5 years old.
- giancarlostoro 5mo agoThe 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.
- rubslopes 5mo agoPeople are afraid to touch dangerous things, like passwords and payment systems. Depending on their skill level, they should indeed be afraid.
- sevenzero 5mo agoI roll both of these at work, from auth to cashless payments to regular online payments. It's not as hard as people make it out to be. Probably a lot harder at big companies with huge attack surfaces and attention though.
- sudoshred 5mo agoSome people enjoy vendor locked managed services for their core infrastructure. Typically this decision is made when building from zero to one in resource constrained environments, and the long term play is to move to your own table/db when it becomes sustainable to do so. The only reason to move to a managed service after having done the work to setup self owned systems is when you need to either a) CYA or b) reduce headcount
- cpard 5mo agoIt feels like a good idea when you are early on in building your product and what matters is quickly iterating on the core features that define your product. It’s not just the table, it’s also the auth and many other things that you know you will need but you would prefer to focus on other stuff. Almost always you start by saying that you will replace that when the time comes and you have proved you have a product and now it’s time to actually build the real thing. Some teams do that and some other, never migrate away and that’s how the GTM of companies like Clerk works.
- Viveletta 5mo agoI'm working at a tiny non-IT company. Outsourcing this work and the security of not having my non IT trained coworkers being able to touch the server is great (but a VM would do the same ofcourse, while costing money). Most of all, we currently don't even need paid tiers of supabase since our software is so small. Given, I feel if you run supabase at a big company you are either lazy and probably have too much budget to spend on useless costs.
- egorfine 5mo agoBecause auth is a productivity tarpit. Anything plan on doing with auth looks simple but almost never is. Homegrown auth can easily sunk half of your dev and support teams. Of course, we're not talking about email/password with "remember me" checkbox kind of auth.
- aatd86 5mo agoI wonder if it is not people being notoriously lazy or clueless at an astonishing degree. How often do you hear that password were saved in plaintext? Surprisingly high in this day and age. People not knowing what salt and pepper is... Vulnerabilities almost as if on purpose... Perhaps it is actually not THAT hard but just like error handling, people don't want to do the unsexy parts and want to delegate those tasks to someone else perhaps. There must be a behavioral pattern there...
- egorfine 5mo ago> want to delegate those tasks to someone else perhaps And this someone's name begins with "Cla" and ends with "ude". So we're going to have a lot more vulnerabilities in the auth code going forward.
- aatd86 5mo agoApparently a mythos loop will mitigate that. /jk We will see I guess... It could also be an opportunity to audit systems in automated ways.
- selfmodruntime 5mo agoYour comment has a bit of an inexperienced smell. Business auth infinitely more complex than saving a user and salting/hashing his password. > There must be a behavioral pattern there... The pattern is that your comment is very far from reality.
- aatd86 5mo agoMy point is that people mess up things as basic as salt and pepper, or encryption at rest. People are not even trying... If we deal with the intricacies of rbac, abac, acl mixed with scopes ,sso, saml, oidc, mfa, etc... I don't find these too conceptually, complex. I mean, it should be avoidable complexity. Most of the complexity is technical debt, bad implementations etc. But by itself it is not THAT complex.
- drbscl 5mo agoBetter Auth is basically just a library / scripts that you run in your application.