3 ms·

you really should scale vertically until you can't anymore. a server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs is going to be able to han

you really should scale vertically until you can't anymore. a server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs is going to be able to handle 99% of companies SQL DB needs.

rjbwork 2y ago
Agree. The microservice "shared nothing" NoSQL-oriented approach has, IMO, shown itself to be a cargo-cult of FAANG practices that are just not worth the downsides in practice at that 99% of companies.
- UltraSane 2y ago
  It does become necessary when you really do need the computing power of hundreds of servers but that is rare.
  - stavros 2y ago
    It's so rare that it's barely worth mentioning. Sure, there are use cases where any rare thing might become necessary, but it's far from the default everyone assumes it to be.
    - UltraSane 2y ago
      And if you need it you should just use something like Google Spanner.
pier25 2y ago
Yep and probably more like 99.999% of companies. But the selling point of Fauna was primarily the data distribution, no? Like GC Spanner but without having to sell and arm and a leg. (Spanner is more affordable now but it used to cost hundreds per month to get started)
chatmasta 2y ago
I mostly agree with you, but a single server won’t solve redundancy and disaster recovery. That doesn’t mean you need to adopt a fully distributed system – a read replica or even periodic backup should be sufficient – but it’s not as simple as “just use a single server.” Stackoverflow is famously powered by a cluster of three vertically scaled database servers.
- bigiain 2y ago
  The complexity you avoid by choosing this 'scale vertically all the way' approach is _huge_. Like you say, deploy read replicas or automate regular backups (with regularly tested restore automation), whatever you need to meet your RTO and RPOs. You need to be able to ignore any ignorant sales/marketing/growth management that try to tell you "we can't afford any downtime at all!!!" and have enough internal political power on the tech side. Tech leadership should be able to document the costs of each extra nine of uptime to senior management and have them acknowledge that occasional second or perhaps even minutes of downtime during failover is acceptable. By the time you start approaching the limits of your server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs - hopefully you no longer need to take advice from randoms on HN because you should by then have 100+ database and network engineers working follow the sun shifts with some _really_ smart and deeply experienced dedicated database leadership managing them. Or, you need to get someone on board to teach all your junior devs or "vibe coders" about database indexes and how to construct queries that don't do multiple fulltable scans just to render some user profile widget on every page load... "But it wrks fine on my laptop!!!" (with a whole 7 user accounts and 47 rows in the user_activity table...)
  - stavros 2y ago
    Honestly, so few companies do this that you'll have a massive execution advantage by just avoiding the network where possible. The "scalability by default" mindset has wasted billions of hours of productivity globally, yet we're still doing it.
- UltraSane 2y ago
  Realistically for a production database you would use a clustering technology like Oracle RAC or SQL Server Always On Failover Clustering or Always On Availability Groups
flyinglizard 2y ago
Won't really solve latency too if you're operating globally. But yes.
- UltraSane 2y ago
  A global multi-master SQL database is one of the hardest things in IT to do correctly. Just use Google Spanner or maybe CockroachDB

you really should scale vertically until you can't anymore. a server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs is going to be able to handle 99% of companies SQL DB needs.

rjbwork 2y ago

Agree. The microservice "shared nothing" NoSQL-oriented approach has, IMO, shown itself to be a cargo-cult of FAANG practices that are just not worth the downsides in practice at that 99% of companies.

UltraSane 2y ago
It does become necessary when you really do need the computing power of hundreds of servers but that is rare.
- stavros 2y ago
  It's so rare that it's barely worth mentioning. Sure, there are use cases where any rare thing might become necessary, but it's far from the default everyone assumes it to be.
  - UltraSane 2y ago
    And if you need it you should just use something like Google Spanner.

pier25 2y ago

Yep and probably more like 99.999% of companies. But the selling point of Fauna was primarily the data distribution, no? Like GC Spanner but without having to sell and arm and a leg. (Spanner is more affordable now but it used to cost hundreds per month to get started)

chatmasta 2y ago

I mostly agree with you, but a single server won’t solve redundancy and disaster recovery. That doesn’t mean you need to adopt a fully distributed system – a read replica or even periodic backup should be sufficient – but it’s not as simple as “just use a single server.” Stackoverflow is famously powered by a cluster of three vertically scaled database servers.

bigiain 2y ago
The complexity you avoid by choosing this 'scale vertically all the way' approach is _huge_. Like you say, deploy read replicas or automate regular backups (with regularly tested restore automation), whatever you need to meet your RTO and RPOs. You need to be able to ignore any ignorant sales/marketing/growth management that try to tell you "we can't afford any downtime at all!!!" and have enough internal political power on the tech side. Tech leadership should be able to document the costs of each extra nine of uptime to senior management and have them acknowledge that occasional second or perhaps even minutes of downtime during failover is acceptable. By the time you start approaching the limits of your server with two 64 core epyc CPUs and 3TB of RAM and 24 NVMe flash SSDs - hopefully you no longer need to take advice from randoms on HN because you should by then have 100+ database and network engineers working follow the sun shifts with some _really_ smart and deeply experienced dedicated database leadership managing them. Or, you need to get someone on board to teach all your junior devs or "vibe coders" about database indexes and how to construct queries that don't do multiple fulltable scans just to render some user profile widget on every page load... "But it wrks fine on my laptop!!!" (with a whole 7 user accounts and 47 rows in the user_activity table...)
- stavros 2y ago
  Honestly, so few companies do this that you'll have a massive execution advantage by just avoiding the network where possible. The "scalability by default" mindset has wasted billions of hours of productivity globally, yet we're still doing it.
UltraSane 2y ago
Realistically for a production database you would use a clustering technology like Oracle RAC or SQL Server Always On Failover Clustering or Always On Availability Groups

flyinglizard 2y ago

Won't really solve latency too if you're operating globally. But yes.

UltraSane 2y ago
A global multi-master SQL database is one of the hardest things in IT to do correctly. Just use Google Spanner or maybe CockroachDB