"Scale" isn't a binary, it's a continuum. "Scales to 60K/s" can be 5 orders of magnitude more than one system needs and 5 orders of magnitude too small for another. Personally I'd knock the general "premature optimization" off the list of "most common developer errors" and put in its place "using techs with the wrong scaling factors". If you use something too small and you exceed its needs, the failure is obvious, but the other way around is a problem too. Bringing in the overhead and management issues of the super scalable techs, as well as their limitations they impose so that they can scale, to a system that would actually be better off with a richer model whose richness prevents it from scaling but would save a lot of effort is also a bad choice.
The ceiling of LISTEN/NOTIFY is small enough that you need to pay attention, and I personally like to have at least an order of magnitude of slack left over even after my most pessimistic load numbers are accounted for, but it's still plenty for a lot of projects, and the integration with the rest of the DB, its availability, its not being another service you have to devops, it's definitely not something that should be simply dismissed out of hand as an option. Even the original 2K/s number they cite is a lot of messages for some systems that are more properly measured in seconds per message.
Nitpick on an otherwise good post, but I don’t think there are very many 6billion RPS systems out there, and those that do exist are almost certainly using bespoke, purpose-built tools
DynamoDB scales much more than that. In one of their dynamodb papers they claimed that the amazon us retail website alone made like 89 millions rps during prime day, a few years ago.
89M rps was the peak across all Amazon systems during 2021 Prime Day. Alexa, Amazon.com and the fulfilment centres together, not one site. But its still very impressieve. But the more importarnt number is the per partition limit, 3000 RCU and 1000 WCU. Horizontal scale is the easy part, a table only gets near it if the partition key actually spreads.
For reference, I've seen Visa marketing materials that suggest their network can do ~70k TPS. There are not very many systems one could conceive of that could do useful work 1/s for ~every human on the planet.
> There are not very many systems one could conceive of that could do useful work 1/s for ~every human on the planet.
Roughly a hundred servers on 100 GbE ports each could handle one small UDP packet per human every second, and would have a plenty of cycles and RAM per human left to actually do some work.
That fits in a shipping container.
Illustrative of course: the point is that "for every human" is not far out there given how crazy powerful hardware has become.
>> For reference, I've seen Visa marketing materials that suggest their network can do ~70k TPS.
> Roughly a hundred servers on 100 GbE ports each could handle one small UDP packet per human every second ...
While there is no correlation between the Visa claim of 70k tps to people on the planet, there is also no correlation to the number of servers needed to process UDP packets.
The "Visa network" is more of a trusted collaboration between a small number of banks operating multi-step transactions than it is an OSI Layer 1 - 5 concern.
There is a tendency in tech to forget that there were highly scalable systems, processing huge numbers of transactions, before the internet and “hyper scalars” were a thing.
Yes, the point is it's difficult to even conceive of something that needs anywhere near the billions of TPS, because generally speaking, humans are not doing something with a computer once per second on average. Far lower. I might use my credit card less than once per day on average.
I think if you expect to be under 60K/s and suddenly find yourself at 20K/s heading for 200K/s-- you have a better problem than if you built for 1M/s and actual load is 20K/s. The unexpected success of the former will pay for a lot of band-aids and scaling, while you're pretty stuck with the cost structure and upfront spent capital in the latter.
IMO one should design for actual anticipated scale with moderate margin, only exceeding this when it's relatively "free" to do so. (If you can buy bigger hardware for a few K, or if solutions are equivalent other than scalability, pick the bigger solution).
In this case it does by hitting hardware maximum. It scales until the max it is possible, due the bottleneck being in the hardware, not in the database or i/o. Check the article again:
> At maximum throughput, Postgres CPU is fully utilized, showing the database is actually saturated instead of bottlenecked on contention.
It doesn’t necessarily follow that because Postgres is “fully utilised” it is hitting “hardware maximum”, or even that it’s not bottlenecked on contention.
As an example, spinlocks can push CPU usage very high whilst being an obvious symptom of contention.
The ceiling of LISTEN/NOTIFY is small enough that you need to pay attention, and I personally like to have at least an order of magnitude of slack left over even after my most pessimistic load numbers are accounted for, but it's still plenty for a lot of projects, and the integration with the rest of the DB, its availability, its not being another service you have to devops, it's definitely not something that should be simply dismissed out of hand as an option. Even the original 2K/s number they cite is a lot of messages for some systems that are more properly measured in seconds per message.