3 ms·

I still wonder so hard what a single bare metal server would have done in terms of performance. [0] May have saved months of planning that may never have been

I still wonder so hard what a single bare metal server would have done in terms of performance. [0] May have saved months of planning that may never have been required. [0]: https://yourdatafitsinram.net/ https://yourdatafitsinram.net/

0xbadcafebee 5y ago
This can quickly become untenable depending on the availability and contractual requirements you have. You're literally building on a single point of failure. And if it's really big and you design wrong, recovery could take weeks.
- louwrentius 5y ago
  Put a slave next to it, that's not the point. AFAIK this is what stackoverflow still does and it works for them. Why not for notion?
  - notJim 5y ago
    Notion may have a much higher proportion of write volume than stackoverflow, given that most of stackoverflow's traffic must be from people who come in from Google, read the answers, and leave. Notion is productivity app, so I would guess most people are actively writing.
  - 0xbadcafebee 5y ago
    If StackOverflow jumped off a bridge, would you jump off one too? You can't base a huge decision like that on "well it worked for somebody else". How did it work for them? What was their platform? What was their data profile? What were their requirements? What was their acceptable level of risk? It could be that they have so many caching layers and lose so little money that they are fine with the database being down for 5 days while they recover. Or that it doesn't actually work that fine for them, because who wants to broadcast that their system is shitty? Or that they've just been lucky. It's not worth finding out the hard way. Build the best system you can with the time and money and expertise you have. Don't cheap out just because you think you can get away with it - especially on the critical stuff.
sa46 5y ago
You'll hit all sorts of other fun problems by vertically scaling. - Many concurrent connections to a single database which Postgres has traditionally not handled well (though improved in recent versions). - You're now on the hook for writing a database control plane. - Backup and restore is much flakier since the data volume is so much larger. Lots of weird shit starts happening when you download tens of TB. - In general, everything is a harder once you start nearing machine limits.
- jamesfinlayson 5y ago
  Yes I thought Postgres didn't recommend more than 700 connections per server (or maybe it was 300) and that was only three or four years ago.

0xbadcafebee 5y ago

This can quickly become untenable depending on the availability and contractual requirements you have. You're literally building on a single point of failure. And if it's really big and you design wrong, recovery could take weeks.

louwrentius 5y ago
Put a slave next to it, that's not the point. AFAIK this is what stackoverflow still does and it works for them. Why not for notion?
- notJim 5y ago
  Notion may have a much higher proportion of write volume than stackoverflow, given that most of stackoverflow's traffic must be from people who come in from Google, read the answers, and leave. Notion is productivity app, so I would guess most people are actively writing.
- 0xbadcafebee 5y ago
  If StackOverflow jumped off a bridge, would you jump off one too? You can't base a huge decision like that on "well it worked for somebody else". How did it work for them? What was their platform? What was their data profile? What were their requirements? What was their acceptable level of risk? It could be that they have so many caching layers and lose so little money that they are fine with the database being down for 5 days while they recover. Or that it doesn't actually work that fine for them, because who wants to broadcast that their system is shitty? Or that they've just been lucky. It's not worth finding out the hard way. Build the best system you can with the time and money and expertise you have. Don't cheap out just because you think you can get away with it - especially on the critical stuff.

sa46 5y ago

You'll hit all sorts of other fun problems by vertically scaling. - Many concurrent connections to a single database which Postgres has traditionally not handled well (though improved in recent versions). - You're now on the hook for writing a database control plane. - Backup and restore is much flakier since the data volume is so much larger. Lots of weird shit starts happening when you download tens of TB. - In general, everything is a harder once you start nearing machine limits.

jamesfinlayson 5y ago
Yes I thought Postgres didn't recommend more than 700 connections per server (or maybe it was 300) and that was only three or four years ago.