Earlier quoted context omitted.
It doesn’t ignore that case, it simply allows them to shift blame whereas the no name vendor does not.
"Nobody has ever been fired for buying IBM"
Go ahead, self-host Postgres
351–360 of 407 posts
Re: Go ahead, self-host Postgres
#352Earlier quoted context omitted.
Disks go bad. RAID is nontrivial to set up. Hetzner had a big DC outage that lead to data loss. Off site backups or replication would help, though not always trivial to fail over.
So can the cloud, and cloud has had more major outages in the last 3 months than I've seen on self-hosted in 20 years. Deploys these days take minutes so what's the problem if a disk does go bad? You lose at most a day of data if you go with the 'standard' overnight backups, and if it's mission critical, you will have already set up replicas, which again is pretty trivial and only slightly more complicated than doing…
Even on PostgreSQL 18 I wouldn't describe self hosted replication as "pretty trivial". On RDS you can get an HA replica (or cluster) by clicking a radio box.
Re: Go ahead, self-host Postgres
#353Earlier quoted context omitted.
Nobody in this thread ever claimed it was better for the users. It's better for the people involved in the decision.
It's not tho, they have workers that they pay not making money, all while footing bigger bill for the "pleasure"
Re: Go ahead, self-host Postgres
#354Earlier quoted context omitted.
If you’re running Kubernetes, CloudNativePG seems to be the “batteries included” HA Postgres cluster that’s becoming the standard in this area.
We’ve recently had a disk failure in the primary and CloudNativePG promoted another to be primary but it wasn’t zero downtime. During transition, several queries failed. So something like pgBouncer together with transactional queries (no prepared statements) is still needed which has performance penalty.
FYI - it's already supported by cloudnativepg [1]
I was playing with this operator recently and I'm truly impressed - it's a piece of art when it comes to postgres automation; alongside with barman [2] it does everything I need and more
[1] https://cloudnative-pg.io/docs/1.28/connection_pooling [2] https://cloudnative-pg.io/plugin-barman-cloud/
Re: Go ahead, self-host Postgres
#355Self-hosting is more a question of responsibility I'd say. I am running a couple of SaaS products and self-host at much better performance at a fraction of the cost of running this on AWS. It's amazing and it works perfectly fine. For client projects, however, I always try and sell them on paying the AWS fees, simply because it shifts the responsibility of the hardware being "up" to someone else. It does not inherent…
Me: “Why are we switching from NoNameCMS to Salesforce?” Savvy Manager: “NoNameCMS often won’t take our support calls, but if Salesforce goes down it’s in the WSJ the next day.”
But perhaps I’m bitter from prior Salesforce experiences.
Re: Go ahead, self-host Postgres
#356Earlier quoted context omitted.
No doubt. Reading this thread leads me to believe that almost no one wants to take responsibility for anything anymore, even hiring the right people. Why even hire someone who isn't going to take responsibility for their work and be part of a team? If an org is worried about the "bus factor" they are probably not hiring the right people and/or the org management has poor team building skills.
Exactly, I just don't understand the grandparent's point, why have a "Postgres person" at all? I hire an engineer who should be able to do it all, no wonder there's been a proliferation of full stack engineers over specialized ones. And especially having worked in startups, I was expected to do many different things, from fixing infrastructure code one day to writing frontend code the next. If you're in a bigger comp…
Re: Go ahead, self-host Postgres
#357Earlier quoted context omitted.
I think you and I simply disagree about your database being a core/critical part of your stack. I believe RDS is good enough for most people, and the only advantage you would have in self hosting is shaving 33% off your instance bill. I'd probably go a step further and argue that Neon/CockroachDB Serverless is good enough for most people.
Access control to your (customer's) data may also be a concern that rules out managed services like RDS.
Re: Go ahead, self-host Postgres
#358I still don't get how folks can hype Postgres with every second post on HN, yet there is no simple batteries-included way to run a HA Postgres cluster with automatic failover like you can do with MongoDB. I'm genuinely curious how people deal with this in production when they're self-hosting.
Re: Go ahead, self-host Postgres
#359[1] https://docs.cloud.google.com/compute/docs/disks/hd-types/hy... [2] https://docs.cloud.google.com/compute/docs/disks/create-snap...
Re: Go ahead, self-host Postgres
#360Earlier quoted context omitted.
I can't tell if this is satire or not with the first sentence and the "0 users" parts of your comment, but I know several solo devs with millions of users who self host their database and apps as well.
What hosting providers do they use/recommend?