Live data from Hacker News

Go ahead, self-host Postgres

pierce.dev

281–290 of 407 posts

Re: Go ahead, self-host Postgres

#281

Earlier quoted context omitted.

I mean, going back a decade might be part of the reason? Configs having issues is like number 1 reason i like the setup so much.. I can configure everything on my local machine and test here, and then just deploy it to a server the same way. I do not have to build a local setup, and then a remote one

Er… what? Even in today’s world with Docker, you have differences between dev and prod. For a start, one is accessed via the internet and requires TLS configs to work correctly. The other is accessed via localhost.

Just fyi, you can put whatever you want in /etc/hosts, it gets hit before the resolver. So you can run your website on localhost with your regular host name over https.

Re: Go ahead, self-host Postgres

#282
post #15

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

Yeah I'm also wondering that. I'm looking for self-host PostgreSQL after Cockroach changed their free tier license but found the HA part of PostgreSQL is really lacking. I tested Patroni which seems to be a popular choice but found some pretty critical problems (https://www.binwang.me/2024-12-02-PostgreSQL-High-Availabili...). I tried to explore some other solutions, but found out the lack of a high level design really makes the HA for PostgreSQL really hard if not impossible. For example, without the necessary information in WAL, it's hard to enforce primary node even with an external Raft/Paxos coordinator. I wrote some of them down in this blog (https://www.binwang.me/2025-08-13-Why-Consensus-Shortcuts-Fa...) especially in the section "Highly Available PostgreSQL Cluster" and "Quorum".

My theory of why Postgres is still getting the hype is either people don't know the problem, or it's acceptable on some level. I've worked in a team that maintains the in house database cluster (even though we were using MySQL instead of PostgreSQL) and the HA story was pretty bad. But there were engineers manually recover the data lost and resolve data conflicts, either from the recovery of incident or from customer tickets. So I guess that's one way of doing business.

Re: Go ahead, self-host Postgres

#283
I started in this industry before cloud was a thing. I did most of the things RDS does the hard way (except being able to dynamically increase memory on a running instance, that's magic to me). I do not want that responsibility, especially because I know how badly it turns out when it's one of a dozen (or dozens) of responsibilities asked of the team.

Re: Go ahead, self-host Postgres

#284
post #212

What irks me about so many comments in this thread is that they often totally ignore questions of scale, the shape of your workloads, staffing concerns, time constraints, stage of your business, whether you require extensions, etc. There is a whole raft of reasons why you might be a candidate for self-hosting, and a whole raft of reasons why not. This article is deeply reductive, and so are many of the comments.

Engineers almost never consider any of those questions. And instead deploy the maximally expensive solution their boss will say ok to.

I find it is the opposite way around. I come up with based on open source tooling and I am forced instead to use which is 100% lock in proprietary BS because is partnered and is subsidising development. This has been a near constant throughout my career.

Re: Go ahead, self-host Postgres

#285

Earlier quoted context omitted.

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

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.

Re: Go ahead, self-host Postgres

#287
post #36

> I'd argue self-hosting is the right choice for basically everyone, with the few exceptions at both ends of the extreme: > If you're just starting out in software & want to get something working quickly with vibe coding, it's easier to treat Postgres as just another remote API that you can call from your single deployed app > If you're a really big company and are reaching the scale where you need trained database e…

Self hosting does not cost you that much at all. It's basically zero once you've got backups automated.

Re: Go ahead, self-host Postgres

#288

I'd argue forget about Postgres completely. If you can shell out $90/month, the only database you should use is GCP Spanner (yes, this also means forget about any mega cloud other than GCP unless you're fine paying ingress and egress). And for small projects, SQLite, rqlite, or etcd. My logic is either the project is important enough that data durability matters to you and sees enough scale that loss of data durabili…

You seem insanely miscalibrated. $90 gets you a dedicated server that covers most projects' needs. data durability isnt some magic that only cloud providers can get you.

If you can lose committed transactions in case of single node data failure, you don't have durability. Then it comes down to do you really care about durability.

Re: Go ahead, self-host Postgres

#289
post #250

Earlier quoted context omitted.

Yes but the fact that it's "not their fault" keeps the person from getting fired. Don't underestimate the power of CYA

This is a major reason the cloud commands such a premium. It’s a way to make down time someone else’s problem. The other factor is eliminating the “one guy who knows X” problem in IT. What happens if that person leaves or you have to let them go? But with managed infrastructure there’s a pool of people who know how to write terraform or click buttons and manage it and those are more interchangeable than someone’s DIY…

Surely 'the other factor' is no factor at all as IaC can target on-prem just as easily as cloud?

Re: Go ahead, self-host Postgres

#290

Earlier quoted context omitted.

I mean, going back a decade might be part of the reason? Configs having issues is like number 1 reason i like the setup so much.. I can configure everything on my local machine and test here, and then just deploy it to a server the same way. I do not have to build a local setup, and then a remote one

Er… what? Even in today’s world with Docker, you have differences between dev and prod. For a start, one is accessed via the internet and requires TLS configs to work correctly. The other is accessed via localhost.

I use a https for localhost, there are a ton of options for that.

But yes, the cert is created differently in prod and there are a few other differences.

But it's much closer then in the cloud.

Post reply on HN