Comment by UltraSane
1 year ago
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.
1 year ago
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.
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.
It does become necessary when you really do need the computing power of hundreds of servers but that is rare.
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.
1 reply →
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.
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...)
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.
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
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)
Won't really solve latency too if you're operating globally. But yes.
A global multi-master SQL database is one of the hardest things in IT to do correctly. Just use Google Spanner or maybe CockroachDB