[lmm]

I've worked for a company that was willing to spend that kind of money on monolithic database servers. They were a top-100 website though, and this was the best part of a decade ago (and thus e.g. in the pre-SSD era).

They were also scrambling to move all their services away from use of that database in favour of a horizontally scaled system that could grow further.

The query rate that can be handled by a single conventional server are pretty monstrous these days. You'd have to be simultaneously a) maybe top-50 website level load (I'm well aware that there's a lot more than websites out there, but at the same time there really aren't that many organizations working at that scale, much as there are many that think they are) and b) confident that you weren't going to grow much.

[dogma1138]

The real world is much bigger than websites/apps.

[lmm]

It is, and I acknowledged that. But it gives a sense of the scale involved. Just as there are very few websites/apps that need to handle, what, 2000 requests/second (and simultaneously don't intend growing by more than a factor of two or so), systems that need that kind of performance in any other field are similarly rare.

[dogma1138]

Not really, it’s also not necessarily not needing to grow but not everything can scale in the same manner as Netflix or Facebook.

Financial systems especially trading platforms need to ensure market fairness they also need to have at the end a single database as you can’t have any conflicts in your orders and the orders need to be executed in the order they came in across the entire system not just a single instance.

This means that even when they do end up with some micro-service-esque architecture for the front end it still talks to a single monolithic database cluster in the end which is used to record and orchestrate everything.

[lmm]

That is indeed one case where a large single-node database makes a certain amount of sense (though it's not the only solution; you need a globally consistent answer for which orders match with which, but that doesn't have to mean a single database node. Looking at the transaction numbers I'd assume that e.g. the busiest books on NYSE must be multi-node systems just because of the transaction rates). But fundamentally there are what, 11 equity exchanges in the US total (and less than half of those are high-volume). And the market fairness requirements are very specific to one particular kind of finance; they're not something that would be needed in healthcare, general enterprise, or most financial applications. Like I said, niche.