WordPress, contrary to what most think, is pretty fast and performant. The reason why so many WordPress sites are slow and can't handle traffic, is because they are run by marketing people who don't understand the tech, and load it up with dozens of poorly written extensions to add user tracking, calls to action, and other dynamic behavior to increase retention. These sorts of practices have nothing to do with whether the framework itself is fast or not.
As has already been mentioned as well below, it is trivial to set up caching on a WordPress site. Most of the WordPress sites that I run are entirely served from cache by nginx. Some are just CMS APIs that I use for a next.js build, and others have the simply static plugin which will rebuild the assets whenever something changes. It's really quite an amazing system, and as much as I do not enjoy PHP or WordPress, there is a reason why it is so ubiquitous now.
WordPress does have a serious problem of underqualified people writing plugins for it and such, but again that is not WordPress's fault, unless you want to blame WordPress for being successful enough to attract those people.
Yeah but I mean: you can't really say that your homegrown Perl script running on a potato can handle 10k req/s if you put caching in front of it. What you're really saying in that case is that your caching solution can handle 10k req/s, which is fine, but besides the point.
Same with Wordpress. Wordpress itself cannot handle that amount of load, which is why you put caching in front of it. Users won't care, I give you that. But if you're talking about how much load a specific software can manage, including putting caching in front of it kind of defeats the point of the conversation.
There's a difference between full page caching like you're describing and in application caching. Most Wordpress caching extensions work internal to the application, not externally by putting something in front of it. With one of the popular extensions you can reduce database calls to basically zero without putting a http cache in front of the application.
I think the implicit point made by GP is to question what the purpose of database calls are to deliver a blog post. If the post were just some HTML and CSS, it should be able to be served with very little processing power. It's unlikely that dynamic template population is needed for blog posts.
> If the post were just some HTML and CSS, it should be able to be served with very little processing power.
Actually, with caching - they are. The database is there so that the person writing the blog post doesn't need to be very technical, or maybe so that they don't need to make a special effort just to update some post.
It doesn't make sense to talk about "how much traffic WordPress can handle" because WordPress is a software that runs on a server. It's like talking about how much traffic nginx "can handle" -- the server setup, hardware, RAM, etc. are key. WordPress running on a potato will handle less traffic than WordPress running on a decent server.
I replaced WP long ago, first with hugo (bad decision), then that with ghost (better decision). Not because of traffic, but because of the sheer number of hacks against the code base of WP appearing as zero days, and the rather extreme upgrading pain (the zero-touch upgrades failed on me a number of times, and I had daily DB backups). I had caching turned up to 11, and that system could easily handle the load (at the peak I was getting a hit every few seconds).
Hugo is/was spectacularly terrible from the perspective of authoring rich content. I could do as well creating a directory tree and writing html by hand. Or markdown.
I guess as I get older, I'm less inclined to spend time on things that don't just work, and don't get in your way with (often bad) opinions on how you should work. WP felt like too great a risk to work with. It was getting expensive to buy plugins to secure the site, when it wasn't generating revenue to offset the costs. Hugo was simply painful to work with. Ghost seems about right. Though grafting in the commenting bits took a little bit of work, which violated my concern about just working.
There are no great blogging solutions. There are a bunch of options of various capability. WP needs caching/php-fpm to work at an acceptable level for reasonable traffic. Hugo (as static pages) wound up not needing much caching. Ghost doesn't need much caching either.
It can be both, but you can have php-level caching (opcache or similar, mainly for making the actual php code faster), wordpress cache plugins (not that great at speed but they can invalidate their cache on changes), reverse-proxy level cache (varnish/nginx or similar, fast but usually requires some work to do invalidation) and perhaps a CDN cache (usually with the cache time set by wordpress via a cache-control header).
For cases like this at least having a nginx/varnish cache with a use use-stale-on-error policy would have been helpful. Even a very short cache-time like 1 second would probably have given a decent hitrate.
I've started using the Simply Static plugin a lot because you can get content-aware cache invalidation and also have nginx serve the files directly so you can avoid hitting any php. You do have to configure nginx properly though or else it won't work, but I didn't find it terribly difficult to do (although I'm already pretty familiar with nginx). Adding varnish is something on my list to try as well, though so far performance has been beyond "good enough" so it's hard to justify the time investment to adding varnish :-)
If you have to use a cache plugin on wordpress, it's much easier to use apache instead of nginx because all cache plugins can automatically configure the cache behavior using automatically generated .htaccess files instead of requiring you to manually configure nginx yourself. Nginx does have speed advantage over apache (and other advantages as well), but if majority of your traffics are going to get served by a static cache, might as well use apache because it's not particularly slower at serving static files compared to nginx, while saving you some configuration headaches.
