5 ms·
> The reason DBs like Mongo or Dynamo exist is because Postgres has a scaling problem. I've used Postgres at a few places and the #1 problem was always high av
by eikenberry 4mo ago
> The reason DBs like Mongo or Dynamo exist is because Postgres has a scaling problem.
I've used Postgres at a few places and the #1 problem was always high availability, not scaling. One Postgres cluster could easily handle 100000 transactions per minute, but when a primary node went down it was a page and manually failing over to the spare then manually replacing the spare. The manual tooling was very finicky but at least it worked, no automated solution came even close. Lack of a good HA story is why I avoid self-managed Postgres as much as possible.
- globular-toast 4mo agoHave you looked into things like CloudnativePG? https://cloudnative-pg.io/ https://cloudnative-pg.io/
- nijave 4mo agoCNPG is quite nice and robust but I'd still be a bit reluctant to stack PG on k8s for really big clusters just because k8s ecosystem moves quite quickly and there's lots of patching/maintenance/churn which means more PG failovers so depends on how well your workload handles that (they're normally only a few seconds)
- globular-toast 4mo agoMost K8s upgrades can happen independently of node reboots etc., you only need to update for OS updates really, but that would be true of anywhere you run PG, even RDS.
- nijave 4mo ago>but that would be true of anywhere you run PG, even RDS It's a little easier to strip down userland if the machine is only running PG. Technically possible on k8s with distros like Talos, Bottlerocket, etc but you still have all the k8s deps on top of PG. It's also a little easier to do defense-in-depth on a dedicated PG machine which means you might have mitigating controls in place to skip security patches (minimal kernel modules, selinux)--possible on k8s but now you're fighting through a 2nd layer of configuration RDS is a bit of a special case because you also have AWS curating and prioritizing updates. You can do that yourself but it's a bit of a time sink scrutinizing every upgrade to see if you _really_ need it. Our RDS instances tend to go 3+ months without restarts
- levkk 4mo agoGood thing we support HA as well: https://docs.pgdog.dev/features/load-balancer/ https://docs.pgdog.dev/features/load-balancer/ Load balancer with health checks and failover, works out of the box. :) Battle-tested at this point too, so could be worth a look.
- eikenberry 4mo agoThat's great news! I'll bookmark this in case I'm forced to manage Postgres again.
- MeetingsBrowser 4mo agoWhat do you use instead?
- eikenberry 4mo agoI tend towards using key-value databases as I find them general purpose enough while being much more robust. I'm not married to any one in particular, depends on the requirements.
- doctorpangloss 4mo agoIs a load balancer HA?
- gchamonlive 4mo agoNot by itself if it's naive, but if it's able to assess target health and avoid degraded instances then it becomes a component in HA, the other being integrating an orchestrator for gracious recovery.
- doctorpangloss 4mo agofrom their docs: > PgDog does not detect primary failure and will not call pg_promote(). It is expected that the databases are managed externally by another tool, like Patroni or AWS RDS, which handle replica promotion.
- tempest_ 4mo agoPatroni serves this niche pretty well at this point.
- parthdesai 4mo agoPatroni 1.0 was released in 2016, i.e ~10 years ago. https://github.com/patroni/patroni https://github.com/patroni/patroni
- nijave 4mo agoYup Patroni handles automatic failures and cluster management quite well
- eikenberry 4mo agoNoted. If I ever have to administer a Postgres setup again I'll take a look. Thanks.
- VirusNewbie 4mo ago~1600 TPS is not 'high scale'.
- inigyou 4mo agoPretty good for 98% of projects though.
- pinkgolem 4mo agoHave you tried cnpg? Worked amazingly well for my usecases