> use Cassandra for scalability and availability, but the cluster ends up being overwhelmed or down for half a day, every month or so, because you need to be a

> use Cassandra for scalability and availability, but the cluster ends up being overwhelmed or down for half a day, every month or so, because you need to be a JVM and Cassandra expert to keep those clusters working. Phew.. it's not just me. My one exposure to Cassandra [1] in a production environment mirrors this experience very closely. I felt a bit like the child in the tale looking at the nude Emperor. Each node held only a single SSD, so increasing database size meant buying an additional multi-thousand-dollar server. Upgrading RAM meant upgrading all the nodes, which became an O(number of nodes) problem in terms of time and cost. The backend team may have had a JVM expert or two, but obviously no Cassandra (nor database in general, and certainly not hardware) knowledge. It was the Ops team who had to keep it limping along and gain the expertise. It's just another case of "it works for FAANG, so it'll work for us" thinking, even though "us" is 2-3 OOM smaller and would be better served by the simplicity of a scaled "up" non-distributed system. [1] Also plenty of experiences with non-Cassandra distributed (usually "NoSQL") databases. The results have ranged from grossly over-engineered (i.e. high cost) to unreliable and/or high-maintenance. Fortunately, rarely both at the same time.