Cassandra 6.0 from a long-term user
I have been using Cassandra since 2008. It was difficult to learn then because there was very little material to learn from. There were few books, production write-ups, architecture notes, or established runbooks. When something went wrong, the answer usually came from mailing lists, source code, Jira tickets, logs, and a cluster you could test on.
Cassandra’s community and the material around it have grown enormously since then. It is still a distributed database that needs thoughtful data modelling, partitions, replicas, consistency levels, compaction, repair, tombstone management, and an understanding of failure domains. That is the normal engineering work of operating Cassandra correctly.
The Cassandra 6.0 line includes substantial work on transaction coordination, metadata and topology, repair scheduling, compaction, I/O, compression, indexing, schema validation, diagnostics, and JVM support. The posts in this series cover those changes individually because they need more than a feature list.
Release status
This series is based on the Apache Cassandra cassandra-6.0 branch, the associated Jira issues, and CEPs. Cassandra 6.0 is pre-release software. At the time of this update, the line is at 6.0-alpha3. Cassandra 5.0.9 is the current GA release, and 6.0 has no beta or release candidate yet. These posts are therefore technical notes on the Cassandra 6.0 line, not a claim that Cassandra 6.0 is the current GA production release.
That distinction is important. A branch shows the direction of implementation and gives operators time to understand the work. A production change must be based on the final release notes, upgrade documentation, compatibility requirements, and support position for the exact version that will be installed.
What the series covers
| Area | Why it deserves attention |
|---|---|
| Accord transactions | Multi-partition transactional coordination changes application design options and needs clear contention, timeout, recovery, and driver tests. |
| Performance and compaction | Direct I/O, allocation reductions, flush work, cursor compaction, SSTable writes, and fsync behaviour can affect CPU, GC, page cache, storage queues, and query tail latency. |
| Repair and diagnostics | A built-in repair scheduler, guardrails, slow-query records, profiling, and richer metrics help operators make repair and failure conditions more explicit. |
| Zstd dictionary compression | Dictionary lifecycle, compression ratio, CPU, memory, SSTable rewrite behaviour, and read cost need table-specific testing. |
| Transactional Cluster Metadata | TCM and CMS replace gossip propagation for critical metadata ordering and make topology and schema state more inspectable. |
| SAI and CQL constraints | New index and constraint capabilities extend modelling options, but query selectivity and write-path rejection behaviour still need disciplined validation. |
| JDK 21 | The Java 21 profile and Generational ZGC affect heap, direct memory, GC CPU, latency, agents, logs, and restart behaviour. |
| Upgrade validation | A binary upgrade, a storage compatibility advance, and optional feature adoption have different rollback boundaries and should not be combined. |
The series starts with coordination and application behaviour, then moves into the storage and operations work behind it.
The series
- Apache Cassandra 6.0 Part 2: Accord Transactions
- Apache Cassandra 6.0 Part 3: Performance Optimisations
- Apache Cassandra 6.0 Part 4: Repair, Guardrails, and Observability
- Apache Cassandra 6.0 Part 5: Zstd Dictionary Compression
- Apache Cassandra 6.0 Part 6: Transactional Cluster Metadata and CMS
- Apache Cassandra 6.0 Part 7: Cursor Compaction and SSTable Writes
- Apache Cassandra 6.0 Part 8: Storage-Attached Indexing and Schema Constraints
- Apache Cassandra 6.0 Part 9: JDK 21 and Generational ZGC
- Apache Cassandra 6.0 Part 10: Upgrade and Production Validation
Testing Cassandra 6.0
- Capture the current application workload, schema, drivers, configuration, topology, repair schedule, storage profile, monitoring, and recovery procedure.
- Test the Cassandra 6.0 binary on its own before changing storage compatibility, JVM settings, drivers, repair policy, or optional features.
- Test each optional capability with a specific reason for enabling it and a defined rollback boundary.
- Include concurrent reads and writes, compaction, repair, backups, streaming, old SSTables, large or tombstone-heavy partitions, node restart, and the operational tools used during an incident.
Synthetic tests can expose a mechanism, but they do not show how a production cluster will behave under all of that work at once.
Cassandra and AxonOps
AxonOps was built around operating Cassandra. We have contributed AxonOps Workbench, an open-source desktop client for Cassandra developers and DBAs, CQLAI, an open-source Cassandra terminal application with AI assistance, and practical Cassandra documentation for operating the database.
Those are some of the ways we contribute back to the Cassandra community. Cassandra 6.0 gives operators more information around metadata, repair, compaction, guardrails, queries, profiling, and table behaviour. AxonOps retains that information alongside host metrics, logs, events, configuration, topology, and history so it is available when a team needs to understand a cluster problem.
For repair specifically, Adaptive Regulation of Cassandra Repair explains how AxonOps uses high-resolution Cassandra and Linux telemetry to adapt repair velocity and parallelism while keeping repair within the required gc_grace_seconds window.
Acknowledging the project
I am grateful to the Apache Cassandra committers and contributors who continue to put effort into this project. The visible release features are only one part of that contribution. Cassandra also depends on people who design and review changes, write tests, maintain CI, benchmark hot paths, investigate regressions, prepare packages and releases, manage compatibility, write documentation, discuss proposals, triage issues, communicate with users, and report difficult production failures with enough detail for them to be fixed.
The individual posts name the contributors credited on their associated tickets and pull requests. Taken together, they show how much work sits behind a release. People work on coordination, metadata, storage, repair, CQL, JVM support, diagnostics, tests, review, documentation, and release engineering. I am very thankful for all of it.