Dear Hannah Wolfe,
in your tweet you say you'd like to know why we need a database cluster for our blog. Thanks for that question, I'm happy to respond.
Every now and then, every piece of hardware fails. That's why we employ clusters for every server app we are running and go to length to avoid single points or failure.
Our cluster is built on the idea of immutable infrastructure. Our apps run inside Docker containers. When a node in our cluster fails, the containers running on that node are started on a different node. In the meantime, identical instances of the apps running on other machines handle the requests.
This principle is common for stateless applications, but we also want it to be valid for databases. To avoid having a database server be a single point of failure, databases must be run on clusters which share parts of their data.
Take CouchDB as an example for a database that is incredibly easy to set up as a cluster, even with master-master-replication. It speaks HTTP. It's ultra-easy to balance requests between many instances.
A blog is just another web application that is supposed to be available. Scaling it over multiple server instances for high availability and even load balancing would be a natural thing for any webapp. The same should be true for the database backend.