Hacker News new | ask | show | jobs
by mastax 1340 days ago
I haven't investigated how true this is, but I've long suspected the reason that PostgreSQL remains relatively difficult to install, configure, replicate, and cluster is that most of the development is done by companies who sell paid solutions that make it easy to install, configure, replicate, and/or cluster.
3 comments

Postgres is super easy to run with these days -- it works great in a container.

Clustering and replication isn't the easiest but that's mostly because it just hasn't been a focus of the postgres machine -- they're making changes that are a bit more fundamental and in my opinion pressing.

Most startups just need to scale a postgres server vertically, not horizontally.

Some of those solutions are themselves open source. Perhaps I am being too generous, but I tend to think in this case it is more that there are many possible approaches to these things and the postgres community simply does not want to bless any one solution just yet.
Either I'm the guy setting up all the vulnerable Postgres installs or I'm just some kind of unknown Postgres savant.

Cany anybody help me out and mention some setup details a blissful idiot like myself might be neglecting in their postgres cluster-ups?

How do you handle replication and failover?

The cluster of 3+ servers must remain consistent, available, and not lose committed transactions when a minority of servers (including the former master) fails.

I’ve had good experiences with logical replication and pg_auto_failover. The cool thing is that the libpq-based clients do some of the work during failovers. You’ll need three nodes though.