4 ms·

Yes, you can scale it quite well vertically. But how about horizontally? It would be nice to have high availability, or even to be able to upgrade the OS and p

by q3k 6mo ago

Yes, you can scale it quite well vertically. But how about horizontally? It would be nice to have high availability, or even to be able to upgrade the OS and postgres itself without downtime.

tuvix 6mo ago
Only played around with it but you can use patroni, etcd and HAproxy to achieve this. It’s a pain, but I believe there was some kind of coolify-style open source application to do this for you but I can’t for the life of me remember its name
- jrnkntl 6mo ago
  autobase[1] is the one I can think of [1] https://github.com/autobase-tech/autobase https://github.com/autobase-tech/autobase
- subhobroto 6mo ago
  You might be thinking of Pigsty? Atleast I hope you are! Nothing else has been as well battletested. Unfortunately, perhaps because if its name, it gets no facetime on HN. Its last few mentions here barely received attention it deserved.
  - sea-gold 6mo ago
    https://github.com/pgsty/pigsty https://github.com/pgsty/pigsty https://pigsty.io/ https://pigsty.io/
levl289 6mo ago
Yep, this is what I think about when “scaling” is mentioned. Maybe I’m too distributed-compute brained, but throwing CPU at a db isn’t what I was hoping would be the answer.
- _3u10 6mo ago
  So the point of distributed compute is to reduce the compute needed? I’ve generally found that distributed compute requires more compute than vertical scaling while getting clobbered by network bandwidth / latency. Theoretically with 2 to 10x compute required and in practice 100 to 500x
  - literalAardvark 6mo ago
    The point of distributed computing is to do computing that you can't do on a vertically scaled system or to increase availability. If you're doing it for other reasons it's usually a mistake.
    - raddan 6mo ago
      The advice I’ve gotten is that you want to move computation to data that is already distributed. The cost of moving large amounts of data usually dwarfs compute costs (usually, not always), and so the performance win comes from distributing the computation and then (depending on the problem) centralizing aggregate results.
    - subhobroto 6mo ago
      Another pretty good reason to do distributed computing is to move the computation closer to where the data is or where the data will be consumed.
  - CodesInChaos 6mo ago
    I think for databases horizontal scaling for writes only makes sense once vertical scaling stops working. It comes with high complexity, annoying limitations, and often higher cost. Horizontal scaling for reads on the other hand is much easier. If you have multiple replicas for high availability, you might as well put them to work. It can also reduce the risk for read heavy tasks interfering with transaction processing. You can even go a step further and replicate to a database that's optimized for analytical tasks. Horizontal scaling for stateless applications (e.g. web servers or job processors) is often easier and more robust than vertical scaling, with little to no downsides.
literalAardvark 6mo ago
Practically trivial to do in 2026 even by hand, and there are a couple of ready to use solutions that even make it automated. If you're running it in kubernetes with cloudnativepg it's even easier. The only thing it doesn't do well is master master replication which is why most of these does it scale posts mostly talk about how slow writes are. And they are pretty slow.
- gbartolini 5mo ago
  It all depends on the storage underneath. If you have got good storage, with CNPG you have comparable results you get on bare metal PostgreSQL.
  - gbartolini 5mo ago
    See for example: https://infohub.delltechnologies.com/en-us/t/edb-postgres-ai-on-openshift-cluster-using-csi-driver-for-dell-powerflex/ https://infohub.delltechnologies.com/en-us/t/edb-postgres-ai...
levkk 6mo ago
Shameless plug[0]. [0] https://pgdog.dev https://pgdog.dev
feverzsj 6mo ago
Only reads scale. You get (much) worse writes for sure.
hasyimibhar 6mo ago
AFAIK that's what Multigres[0] and Neki[1] are trying to solve. [0] https://multigres.com/ https://multigres.com/ [1] https://neki.dev/ https://neki.dev/
- deleted 5mo ago
  [deleted]

by q3k 6mo ago

Yes, you can scale it quite well vertically. But how about horizontally? It would be nice to have high availability, or even to be able to upgrade the OS and postgres itself without downtime.

tuvix 6mo ago

Only played around with it but you can use patroni, etcd and HAproxy to achieve this. It’s a pain, but I believe there was some kind of coolify-style open source application to do this for you but I can’t for the life of me remember its name

jrnkntl 6mo ago
autobase[1] is the one I can think of [1] https://github.com/autobase-tech/autobase https://github.com/autobase-tech/autobase
subhobroto 6mo ago
You might be thinking of Pigsty? Atleast I hope you are! Nothing else has been as well battletested. Unfortunately, perhaps because if its name, it gets no facetime on HN. Its last few mentions here barely received attention it deserved.
- sea-gold 6mo ago
  https://github.com/pgsty/pigsty https://github.com/pgsty/pigsty https://pigsty.io/ https://pigsty.io/

levl289 6mo ago

Yep, this is what I think about when “scaling” is mentioned. Maybe I’m too distributed-compute brained, but throwing CPU at a db isn’t what I was hoping would be the answer.

_3u10 6mo ago
So the point of distributed compute is to reduce the compute needed? I’ve generally found that distributed compute requires more compute than vertical scaling while getting clobbered by network bandwidth / latency. Theoretically with 2 to 10x compute required and in practice 100 to 500x
- literalAardvark 6mo ago
  The point of distributed computing is to do computing that you can't do on a vertically scaled system or to increase availability. If you're doing it for other reasons it's usually a mistake.
  - raddan 6mo ago
    The advice I’ve gotten is that you want to move computation to data that is already distributed. The cost of moving large amounts of data usually dwarfs compute costs (usually, not always), and so the performance win comes from distributing the computation and then (depending on the problem) centralizing aggregate results.
  - subhobroto 6mo ago
    Another pretty good reason to do distributed computing is to move the computation closer to where the data is or where the data will be consumed.
- CodesInChaos 6mo ago
  I think for databases horizontal scaling for writes only makes sense once vertical scaling stops working. It comes with high complexity, annoying limitations, and often higher cost. Horizontal scaling for reads on the other hand is much easier. If you have multiple replicas for high availability, you might as well put them to work. It can also reduce the risk for read heavy tasks interfering with transaction processing. You can even go a step further and replicate to a database that's optimized for analytical tasks. Horizontal scaling for stateless applications (e.g. web servers or job processors) is often easier and more robust than vertical scaling, with little to no downsides.

literalAardvark 6mo ago

Practically trivial to do in 2026 even by hand, and there are a couple of ready to use solutions that even make it automated. If you're running it in kubernetes with cloudnativepg it's even easier. The only thing it doesn't do well is master master replication which is why most of these does it scale posts mostly talk about how slow writes are. And they are pretty slow.

gbartolini 5mo ago
It all depends on the storage underneath. If you have got good storage, with CNPG you have comparable results you get on bare metal PostgreSQL.
- gbartolini 5mo ago
  See for example: https://infohub.delltechnologies.com/en-us/t/edb-postgres-ai-on-openshift-cluster-using-csi-driver-for-dell-powerflex/ https://infohub.delltechnologies.com/en-us/t/edb-postgres-ai...

levkk 6mo ago

Shameless plug[0]. [0] https://pgdog.dev https://pgdog.dev

feverzsj 6mo ago

Only reads scale. You get (much) worse writes for sure.

hasyimibhar 6mo ago

AFAIK that's what Multigres[0] and Neki[1] are trying to solve. [0] https://multigres.com/ https://multigres.com/ [1] https://neki.dev/ https://neki.dev/

deleted 5mo ago
[deleted]