Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go ahead, self-host Postgres

pierce.dev

Post reply on HN
Print view View original

321–330 of 407 posts

Re: Go ahead, self-host Postgres

#321

Post by bg24 »

alemanek wrote: post #174
paulryanrogers wrote: post #160

Earlier 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.

As someone who has set this up while not being a DBA or sysadmin. Replication and backups really aren’t that difficult to setup properly with something like Postgres. You can also expose metrics around this to setup alerting if replication lag goes beyond a threshold you set or a backup didn’t complete. You do need to periodically test your backups but that is also good practice. I am not saying something like RDS do…

Yes. Also you can have these replicas of Postgres across regions.

Re: Go ahead, self-host Postgres

#322

Post by mcny »

paulryanrogers wrote: post #160
mattmanser wrote: post #136

Earlier quoted context omitted.

Over 20 year I've had lots of clients on self-hosted, even self-hosting SQL on the same VM as the webserver as you used to in the long distant past for low-usage web apps. I have never, ever, ever had a SQL box go down. I've had a web server go down once. I had someone who probably shouldn't have had access to a server accidentally turn one off once. The only major outage I've had (2/3 hours) was when the box was als…

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.

One thing that will always stick in my mind is one time I worked at a national Internet service provider.

The log disk was full or something. That's not the shameful part though. What followed is a mass email saying everyone needs to update their connection string from bla bla bla 1 dot foo dot bar to bla bla bla 2 dot foo dot bar

This was inexcusable to me. I mean this is an Internet service provider. If we can't even figure out DNS, we should shut down the whole business and go home.

Re: Go ahead, self-host Postgres

#323

Post by zelphirkalt »

yunwal wrote: post #285
dilyevsky wrote: post #261

Earlier quoted context omitted.

This ignores the case when BigVendor is down for your account and your account only and support is mia, which is not that uncommon ime

It doesn’t ignore that case, it simply allows them to shift blame whereas the no name vendor does not.

So in the end it's not better for the users at all, it's just for non-technical people to shift blame. Great "business reasoning".

Re: Go ahead, self-host Postgres

#324

Post by vitabaks »

Just use Autobase for PostgreSQL

https://github.com/vitabaks/autobase

automates the deployment and management of highly available PostgreSQL clusters in production environments. This solution is tailored for use on dedicated physical servers, virtual machines, and within both on-premises and cloud-based infrastructures.

Re: Go ahead, self-host Postgres

#325

Post by WJW »

zelphirkalt wrote: post #323
yunwal wrote: post #285

Earlier quoted context omitted.

It doesn’t ignore that case, it simply allows them to shift blame whereas the no name vendor does not.

So in the end it's not better for the users at all, it's just for non-technical people to shift blame. Great "business reasoning".

Nobody in this thread ever claimed it was better for the users. It's better for the people involved in the decision.

Re: Go ahead, self-host Postgres

#326

Post by lukaslalinsky »

Nextgrid wrote: post #209
ninkendo wrote: post #202

Earlier quoted context omitted.

You don’t need to use networked storage, the zalando postgres operator just uses local storage on the host. It uses a StatefulSet underneath so that pods will stay on the same node until you migrate them.

But if I'm pinning it to dedicated machines then Kubernetes does not give me anything, but I still have to deal with its tradeoffs and moving parts - which from experience are more likely to bring me down than actual hardware failure.

I run PostgreSQL+Patroni on Kubernetes where each instance is a separate StatefulSet pinned to dedicated hosts, with data on local ZFS volumes, provisioned by the OpenEBS controller.

I do this for multiple reasons, one is that I find it easier to use Kubernetes as the backend for Patroni, rather than running/securing/maintaining just another etcd cluster. But I also do it for observability, it's much nicer to be able to pull all the metrics and logs from all the components. Sure, it's possible to set that up without Kubernetes, but why if I can have the logs delivered just one way. Plus, I prefer how self-documenting the whole thing is. No one likes YAML manifests, but they are essentially running documentation that can't get out of sync.

Re: Go ahead, self-host Postgres

#327

Post by petterroea »

kunley wrote: post #318
petterroea wrote: post #66

I have ran (read: helped with infrastructure) a small production service using PSQL for 6 years, with up to hundreds of users per day. PSQL has been the problem exactly once, and it was because we ran out of disk space. Proper monitoring (duh) and a little VACUUM would have solved it. Later I ran a v2 of that service on k8s. The architecture also changed a lot, hosting many smaller servers sharing the same psql serve…

Psql (lowercase) is the name of the textual sql client for PostgreSQL. For a general abbreviation we rather use "Pg".

Good catch, thx

Re: Go ahead, self-host Postgres

#328

Post by growse »

WJW wrote: post #325
zelphirkalt wrote: post #323

Earlier quoted context omitted.

So in the end it's not better for the users at all, it's just for non-technical people to shift blame. Great "business reasoning".

Nobody in this thread ever claimed it was better for the users. It's better for the people involved in the decision.

And this speaks to the lack of alignment about what's good for the decision makers Vs what's good for the customer.

Re: Go ahead, self-host Postgres

#329

Post by abrookewood »

computerfan494 wrote: post #247
abrookewood wrote: post #239

Earlier quoted context omitted.

"I really dream PostgreSQL will be as reliable as MongoDB" ... someone needs to go and read up on Mongo's history! Sure, the PostrgreSQL HA story isn't what we all want it to be, but the reliability is exceptional.

Postgres violated serializability on a single node for a considerable amount of time [1] and used fsync incorrectly for 20 years [2]. I personally witnessed lost data on Postgres because of the fsync issue. Database engineering is very hard. MongoDB has had both poor defaults as well as bugs in the past. It will certainly have durability bugs in the future, just like Postgres and all other serious databases. I'm not…

Thanks for adding that - I wasn't aware.
Post reply on HN