Apache Cassandra 4.0 finally goes GA
It's been a long time coming – 13 months in fact since the beta was announced – but Apache Cassandra 4.0 has now entered general release and is considered production-ready. Actually, the code went live yesterday afternoon, but today is the day that the Cassandra community is hauling out the fireworks.
Now get this – going forward, the Apache Cassandra project is planning to commit to 6-month release cycles. Hold that thought.
The 4.0 release was positioned by the community as a fairly boring release – in that the brunt of the effort was in locking things down to make this the most stable dot zero release in Cassandra history. Pre-4.0, dot zero Cassandra releases would have bugs that would have wound up being patched in subsequent dot releases. On this time round, the community opted for the mundane blocking and tackling.
Colleague Steven J. Vaughan-Nichols provided the lowdown on what the 4.0 release would include back last June. To recap, the headline was that this would be "the most stable Apache Cassandra in history." Among the new features were change data capture streaming which is typically used for replication, with throughput up to 5x faster for populating new clusters and up to 25% for reads and writes. Additionally, they have hardened consistency checking between replicas, better known as incremental repair, and have added real-time audit logging that will help with observability.
While the beta stage took over a year, according to DataStax vice president of developer relations Patrick McFadin, there remained white knuckle episodes up until the last moment. Even as recently as last week, there was a bug (subsequently patched) that delayed the release by eight days.
While not part of the 4.0 release, the community made changes to the development process that will, hopefully, make the next cycle more manageable, and quicker. First, the project has now formalized the process for adding new features, making it operate more like mature projects such as Spark and Kafka; before, adding features was a more ad hoc activity.
On the agenda for the 4.1 and 5.0 will be how to build more cloud-native support into Cassandra. The Kubernetes operator that DataStax developed is a prime candidate, but the implementation (K8ssandra) will likely remain a vendor matter. DataStax will offer the secondary index that it introduced last year. Other items on the wish list could include guardrails that prevent practices such as submitting the query from hell or overloading a table with too many indexes.
More importantly, the Cassandra community is changing the release cycle. Going from Cassandra 3.0 to 4.0 took six years, and as noted, the beta for the 4.0 release stretched over 13 months. Going forward, the project is committing to 6-month release cycles, with six months being the dot release, and 12 months being the major release. It's a response to expectations that, as your platform is increasingly being consumed as a cloud service, the market expects more frequent updates. So if there's nothing else exciting on the new feature list, adding discipline and speed to the development cycle for Apache Cassandra would certainly fit the bill.
Disclosure: DataStax is a dbInsight client.