Apache Cassandra Alternatives

Does this scenario sound familiar? Your application’s data and scalability needs warrant a distributed NoSQL database. A wide-column NoSQL database will deliver the fastest querying speed, so you look to Apache Cassandra. It’s utilized by thousands of companies including Netflix and Apple, is consistently ranked high in DB-Engines popularity, and is free with a robust open source community. So why do many Cassandra users later find themselves seeking alternatives?

It’s not for lack of support. There are several companies with Cassandra expertise that provide 24×7 enterprise-class support if needed. And if you wish to be free of cluster infrastructure and administration, you can utilize a fully managed Cassandra cloud service such as DataStax Astra and Amazon Managed Apache Cassandra Service. But these won’t solve slow release cycles and a lack of critical features. And they won’t address the two biggest challenges with Cassandra: performance at scale and the associated costs.

Cassandra is built in Java and runs in a Java Virtual Machine (JVM). As a result, it must contend with Java overhead and the inherent impact on throughput and latency. For small clusters, it’s often tolerable. But as environments grow, performance challenges mount. Java consumes a lot of memory and managing memory is an art form. Garbage collection (GC) pauses – when all application traffic stops – can run hundreds of milliseconds to seconds and become a frequent headache. Determining optimum heap size and adjusting JVM parameters to mitigate GC issues and improve performance requires expertise, varies by workload, and consumes staff resources.

Adding more nodes is a common remedy for GC challenges and boosting performance, but with often disappointing results. Because Java’s “write once, run anywhere” architecture hides low-level system attributes, Cassandra is hindered from making efficient use of system hardware. It’s why clusters with fewer, larger nodes fail to outperform clusters with more, smaller nodes. It’s why keeping nodes under 1TB is generally recommended. And it’s why servers with newer, faster processors, faster memory, and faster I/O often fall short of expectations. All of this leads to node sprawl, rising costs, and never-ending performance tuning.