4 ms·

Are you running at a scale where a single master DB isn't sufficient? Because nowadays you can get servers with about 192GB of RAM and 32 CPU cores. Clusterin

by nickjj 8y ago

Are you running at a scale where a single master DB isn't sufficient? Because nowadays you can get servers with about 192GB of RAM and 32 CPU cores. Clustering seems like one of those "what if"[0] scenarios where maybe if you were operating at roflcopter scale you might need it but for 99.9999999999999% of cases, a single master DB is more than enough -- at least with a well designed SQL db like Postgres. [0]: https://nickjanetakis.com/blog/optimize-your-programming-decisions-for-the-95-percent-not-the-5-percent https://nickjanetakis.com/blog/optimize-your-programming-dec...

chrisfosterelli 8y ago
Or maybe you just want to have a hiccup on a single machine not take down your entire application?
- vvillena 8y ago
  Hot standbys work well in Postgres. As OP said, the issue is clustering, not replication.
threeseed 8y ago
It’s not about scale it’s reliability. Servers especially in the cloud can go down pretty quickly. Not just for hardware reasons either. I can’t imagine any company crazy enough to run one server like you’re describing. Definitely wouldn’t pass any enterprise service continuity testing/review that’s for sure.
- marcosdumay 8y ago
  Clusters for reliability are very different from clusters for performance, and very well supported by Postgres.
atonse 8y ago
As others said, it isn't about scale, but reliability, and even things like patching. With a load balancer, you can easily patch your web servers, but very often, DB servers go unpatched and un-upgraded for years since they aren't in a self-healing cluster. To add some detail, I worked on an e-commerce system that was like this. We would've lost something like $60k an hour if we rebooted the database server (yes, one server, nobody expected this sort of growth). So we didn't touch it for 3 years until it was about to run out of disk space. Then we had no choice, but then we set it up as a fully replicated system with a ton of disk space, making future patching easier.
zorga 8y ago
A single master db isn't sufficient for any production app; you should have no single points of failure and that includes having at a minimum 2 db's. Clustering isn't a what if scenario, it's a must have for any serious business, single points of failure are not acceptable.
- manigandham 8y ago
  100% uptime is impossible and the vast majority of companies do not need anywhere near the 99.99% they claim is necessary, nor can they actually pay for it. A 30-second outage to switch to a replica is perfectly fine for production.
  - zorga 8y ago
    If you have a replica, you have two db's already as I've suggested. And no one said anything about uptime; the point was single point of failure, not uptime. When I said single master, I just meant a single db as opposed to a master/slave setup.
    - Tostino 8y ago
      The GP said single master, not single database.
      - zorga 8y ago
        I am the GP, I think I know what I meant better than you, which is why I clarified that in the comment you just replied to.
deleted 8y ago
[deleted]
gaius 8y ago
Because nowadays you can get servers with about 192GB of RAM and 32 CPU cores. You can get servers with 2T of memory and 96 cores off the shelf for a few years now. Real world workloads that you can't run on these boxes are few and far between. But everyone worries about "scalability" like they'll ever run into those limits.

by nickjj 8y ago

chrisfosterelli 8y ago

Or maybe you just want to have a hiccup on a single machine not take down your entire application?

vvillena 8y ago
Hot standbys work well in Postgres. As OP said, the issue is clustering, not replication.

threeseed 8y ago

It’s not about scale it’s reliability. Servers especially in the cloud can go down pretty quickly. Not just for hardware reasons either. I can’t imagine any company crazy enough to run one server like you’re describing. Definitely wouldn’t pass any enterprise service continuity testing/review that’s for sure.

marcosdumay 8y ago
Clusters for reliability are very different from clusters for performance, and very well supported by Postgres.

atonse 8y ago

As others said, it isn't about scale, but reliability, and even things like patching. With a load balancer, you can easily patch your web servers, but very often, DB servers go unpatched and un-upgraded for years since they aren't in a self-healing cluster. To add some detail, I worked on an e-commerce system that was like this. We would've lost something like $60k an hour if we rebooted the database server (yes, one server, nobody expected this sort of growth). So we didn't touch it for 3 years until it was about to run out of disk space. Then we had no choice, but then we set it up as a fully replicated system with a ton of disk space, making future patching easier.

zorga 8y ago

A single master db isn't sufficient for any production app; you should have no single points of failure and that includes having at a minimum 2 db's. Clustering isn't a what if scenario, it's a must have for any serious business, single points of failure are not acceptable.

manigandham 8y ago
100% uptime is impossible and the vast majority of companies do not need anywhere near the 99.99% they claim is necessary, nor can they actually pay for it. A 30-second outage to switch to a replica is perfectly fine for production.
- zorga 8y ago
  If you have a replica, you have two db's already as I've suggested. And no one said anything about uptime; the point was single point of failure, not uptime. When I said single master, I just meant a single db as opposed to a master/slave setup.
  - Tostino 8y ago
    The GP said single master, not single database.
    - zorga 8y ago
      I am the GP, I think I know what I meant better than you, which is why I clarified that in the comment you just replied to.

deleted 8y ago

[deleted]

gaius 8y ago

Because nowadays you can get servers with about 192GB of RAM and 32 CPU cores. You can get servers with 2T of memory and 96 cores off the shelf for a few years now. Real world workloads that you can't run on these boxes are few and far between. But everyone worries about "scalability" like they'll ever run into those limits.