WordPress is not my favorite thing and some of the available plug-ins do terrible things with MySQL, but the problem is not too low default connections; it's too many PHP workers. WordPress is generally focused enough that most of the wall time is spent in waiting for the database, so you want to optimize for throughput; one or two workers per cpu thread is plenty for that. More concurrency than execution available reduces throughput, so it's better to queue requests in your http layer than to process multiple at once.
Large numbers of MySQL connections are more appropriate when the web pages do a mix of things, but more/mostly idle DB wise; in that case, you might still want persistent connections to reduce round trips before a query, but are less likely to have a query backlog large enough where task switching overhead becomes significant.
The only difference between this and adding a cache is that the cache is another piece of software in your production stack.
Vanilla SSGs are so simple I ended up writing a basic one out of a markdown and jinja parser in Python every time (for example: https://github.com/eatonphil/notes.eatonphil.com/blob/master...).
If I were not lazy I might learn one of the major ones like Hugo.
It doesn't matter what SSG you pick, they all produce the exact same kind of thing.
But the point was to make a comparison to a Raspberry Pi and emphasize that you do not special compute to withstand thousands of page views. Even S3 and GH Pages are overkill in terms of the compute behind both of them vs. what you need minimally.
The blogs that go down here typically back every request by MySQL (ahem, WordPress) which is totally unnecessary and often actively harmful since MySQL has very low default total connections allowed.
The point being: don't serve requests backed by a database unless the results are likely to change very dynamically!