Apache Cassandra is trusted because it changes carefully. That same care can leave useful fixes and performance work waiting a long time before operators can run them. The RustyRazorblade branches are a practical answer: keep Cassandra’s protocol and operating model, but create a place to integrate, test, and ship focused improvements sooner.
This is a snapshot of two fork branches on 26 October 2026. It is not the Apache Cassandra 5.0 or 6.0 release plan, and branch work should not be read as an upstream commitment. Our intent is to contribute every change back to Apache Cassandra; acceptance and release decisions remain with the Apache Cassandra community. We expect the details to move as measurement and review continue.
01 / Two branches, two jobs
One makes 5.0 easier to run. The other changes how data moves through the engine.
The5.0.9 branchis deliberately compact: six commits above the Apache 5.0.9 tag. It pulls forward runtime and I/O work that can help operators now, then makes one opinionated configuration choice visible at the tip.
The6.0 branchis the deeper experiment: 21 branch-specific commits spanning 173 files. Most of that delta develops and tests cursor-based paths for compaction, validation, cleanup, flush, and selected reads. The last commit addresses concurrent metadata proposals.
02 / Cassandra 5.0.9
A production-minded baseline.
The 5.0.9 branch is not a rewrite. It is a curated set of changes aimed at modern runtimes, more useful operational signals, and less cache disruption during compaction.
JDK 21 support
The branch carries the Apache patch that adds JDK 21 build and runtime support, including server and client JVM option files, packaging, tooling, and test changes. This is compatibility work. It is not a claim that a newer JDK automatically makes every workload faster.
Inspect the JDK 21 commitGC signals that distinguish pauses from concurrent work
ZGC and Shenandoah report concurrent phases that are not stop-the-world pauses. Treating both with one threshold makes alerts harder to interpret. The branch adds separate log and warning thresholds for concurrent phases, while retaining the existing pause thresholds.
gc_concurrent_phase_log_thresholdgc_concurrent_phase_warn_thresholdInspect the GC thresholds commit Direct I/O for compaction reads
Compaction commonly scans SSTable data once. Filling the OS page cache with that stream can evict pages needed by foreground reads. The direct-I/O path uses aligned buffers and read-ahead to bypass the page cache, and includes a startup capability check plus dedicated reader tests.
The branch’s final “defaults” commit enablescompaction_read_disk_access_mode: direct in the shipped and test configuration. That choice is intentionally easy to find and easy to reverse. It still needs workload- and platform-specific measurement; bypassing cache is not universally better.
Non-interactive CI that stays non-interactive
Two small fixes make the repository’s run-citooling read JENKINS_PASSWORD when supplied instead of blocking on a password prompt. It is not a database feature, but reproducible automation is part of releasing database changes safely.
03 / Cassandra 6.0
Make the cursor path a real storage pipeline.
Cassandra’s established iterator path materialises Java objects as data moves through reads and compaction. The cursor work explores a more streaming-oriented path: carry compact descriptors and wire data farther through the pipeline, materialise later, and avoid allocations where values can be compared or copied directly.
The objective is not “replace every iterator.” It is to build a narrower path with explicit support gates, prove byte-for-byte and semantic parity, and expand the supported surface only when the tests justify it.
Compaction grows up
The first commits add BTI trie-index support and then harden the cursor compactor around completed cursors, multi-output writer switches, early-open boundaries, key-cache migration, range tombstones, and counter columns. Allocation-focused commits copy the partition key once and stop creating a detached key for every partition on the write path.
The same machinery moves into maintenance
Repair validation and cleanup are not ordinary compactions: they have different output and accounting requirements. Dedicated commits add a cursor-backed validation iterator for repair and cursor-backed cleanup, including tombstone-count parity and differential tests rather than assuming the normal compaction path is sufficient.
Flush and reads are opt-in experiments
The branch adds cursor-based memtable flush behindcursor_flush_enabled and a cursor-based single-partition read path behind cursor_reads_enabled. Both default to false. The read path admits only supported shapes; reversed queries, multi-slice filters, row-cached tables, legacy formats, and other unsupported cases remain on the existing iterator path.
Inside the supported surface, the work explores merged SSTable and memtable legs, index seeks, filter and limit pushdown, late materialisation, and response transcoding. Those are implementation capabilities under test, not yet a blanket performance promise.
Correctness evidence is part of the implementation
The 6.0 delta is large because the test surface is large. Differential suites run cursor and iterator paths against the same inputs and compare outputs across BIG and BTI formats, counters, reversed clustering, range tombstones, Leveled, TimeWindow, and Unified compaction, repair validation, cleanup, flush, read filters, limits, serialization, and allocation gates. Negative-control hooks deliberately corrupt decisions so the harness proves it can catch the failure it is meant to detect.
Concurrent schema changes stop wasting the same epoch
Patrick McFadin’s metadata change addresses a different kind of hot path. Concurrent local DDL could read the same Cluster Metadata Service epoch, race to propose the same next epoch, and burn through retries even while request time remained. The fix serialises the local read–execute–propose cycle behind a fair, deadline-bounded lock.
It deliberately releases the lock before follower waits, backoff, or log fetching, and it does not pretend to solve races between separate CMS members. The goal is narrower: stop local threads creating useless contention where only one proposal can win.
Inspect the metadata proposal fix04 / How we ship
Compatibility first. Claims after evidence.
ChronitonDB is the vehicle for turning this kind of focused work into something operators can evaluate and, eventually, depend on. AxonOps will provide the release engineering and long-term stewardship; the design, benchmarks, failures, and code stay open to review. The fork is a proving ground, not the final destination: our intent is to contribute every change back to Apache Cassandra.
- Keep the Cassandra protocol and operating model recognisable.
- Gate experimental paths and preserve a known fallback.
- Compare new and old implementations on identical data.
- Publish workload-specific measurements before making performance claims.
- Prepare changes for upstream review and work with the Apache Cassandra community, not around it.
The 5.0 branch is the near-term operating baseline. The 6.0 branch is where the deeper storage-path work earns its confidence. They move at different speeds on purpose.
05 / Follow the work