Apache Cassandra 6, Automated Repair – Why CEP-37 Changes Everything for Database Operations

If you have run Apache Cassandra in production, you already know the ritual. Repair must happen regularly, or your cluster will drift. Anti-entropy repair keeps replicas consistent across nodes. Without it, deleted data can resurrect, stale reads multiply, and compaction efficiency degrades.

The problem was never that Cassandra could not repair. The problem was that repair lived entirely outside the database. Teams stitched together cron jobs, Reaper instances, custom scripts, and third-party tooling, and those solutions kept breaking during upgrades, topology changes, or on-call incidents.

Cassandra 6 changes this with CEP-37: Automated Repair Inside Cassandra. For the first time, repair is a first-class, natively scheduled, operationally observable process inside the database engine itself.

At Ksolves, we manage Cassandra clusters across banking, telecom, and enterprise clients. This is one of the most operationally impactful changes we have seen in years. This blog explains exactly why.

The Repair Problem in Production: What Teams Actually Face

Repair has always been a deceptively simple concept. In practice, it is one of the most operationally challenging aspects of running Cassandra at scale. Here is what production teams deal with:

The result: teams that ran repair well had dedicated Cassandra expertise on staff. Everyone else was operating with silent drift, hoping nothing surfaced at scale.

What CEP-37 Actually Does: Inside the Database

CEP-37 introduces a native repair scheduler that runs as a background process inside Cassandra, with full awareness of cluster topology, workload, and repair state. Here is what that means in practice:

Repair Is Now a Background Service, Not an External Job

In Cassandra 6, repair scheduling is embedded in the database process. You configure it once, setting repair frequency, parallelism, and priority. From there, the cluster handles execution automatically, with no external processes to maintain.

Full and Incremental Repair Both Supported

CEP-37 supports both full repair (reconciling entire token ranges across replicas) and incremental repair (tracking which SSTables have already been repaired and skipping them). For large clusters, incremental repair dramatically reduces repair duration and I/O cost.

Safeguards and Scheduling Controls

The automated repair engine includes built-in safeguards to protect cluster performance:

• Rate limiting: repair is throttled to avoid impacting foreground read/write workloads
• Backpressure: if nodes are under stress, repair automatically backs off
• Topology awareness: repair scheduling respects DC boundaries and rack placement, avoiding cross-DC repair floods
• Priority configuration: operators can tune whether repair runs aggressively or passively based on cluster criticality

Observable and Auditable

One of the most underrated aspects of CEP-37 is observability. Because repair now lives inside the database, its state is queryable via system views. You can inspect what is being repaired, what has already been repaired, and when. This replaces guesswork and log-diving with direct operational visibility.

Already Backported to Cassandra 5.0.8

Notably, the Apache project backported CEP-37 to Cassandra 5.0.8 in April 2026. Production clusters on the 5.x branch can therefore benefit from automated repair without waiting for a full Cassandra 6 upgrade, a strong signal of the feature’s maturity and community confidence.

How This Changes Upgrade Planning for Your Cluster

If you are currently running repair with Reaper or cron-based scripts, your upgrade path to Cassandra 6 (or even 5.0.8) will include a transition from external repair orchestration to native repair. Here is how Ksolves approaches this transition with clients:

What This Means for Teams Running Cassandra Without Dedicated Expertise

The teams that benefit most from CEP-37 are those running Cassandra without full-time Cassandra engineers on staff. For these teams, automated repair is not a convenience. It is a safety net.

Previously, a team that let repair slide for three to four weeks could see:

• Tombstone floods degrading read latency
• Data resurrection after node recovery
• Compaction storms triggered by unresolved replica drift

With native automated repair, the database enforces a repair cadence regardless of team capacity. This is the same principle that makes automatic compaction valuable: core maintenance tasks should not require manual intervention.

Ksolves Recommendation: Enable Automated Repair Early

We recommend treating CEP-37 as a high-priority upgrade driver. Specifically:

• Cassandra 5.x clusters: Upgrade to 5.0.8 and test automated repair in a non-production environment immediately. This is a low-risk path to a significant operational improvement.
• Cassandra 4.x clusters: Add CEP-37 enablement to your Cassandra 6 migration planning. Treat it as a first-day configuration task, not an afterthought.
• Clusters currently using Reaper: Do not decommission Reaper immediately. Run both in parallel through at least one full repair cycle before cutting over to validate coverage.
• High-write keyspaces: Configure more aggressive repair intervals for keyspaces with heavy delete or TTL workloads. The default settings are conservative.

Ready to Upgrade to Apache Cassandra 6?

Navigating a Cassandra 6 migration, or deciding whether to take the 5.0.8 early path, involves real tradeoffs around cluster topology, keyspace design, and repair configuration. Ksolves’ Big Data team has hands-on experience running and upgrading Cassandra clusters for banking, telecom, and enterprise clients, and we bring that experience to every engagement.

Our Cassandra services include:

• Migration planning and execution: end-to-end guidance from Cassandra 4.x or 5.x to Cassandra 6, including CEP-37 enablement and Reaper decommissioning
• Cluster health audits: baseline assessments of repair coverage, compaction behavior, and replica consistency before you migrate
• Performance tuning: repair scheduling, compaction strategy, and keyspace-level configuration tailored to your workload
• 24/7 managed operations: ongoing monitoring, incident response, and proactive maintenance for production Cassandra clusters
• Proof-of-concept support: safe, sandboxed testing of new Cassandra 6 features, including automated repair, before production rollout

Whether you are running a handful of nodes or a multi-datacenter deployment at scale, Ksolves can help you plan, test, and execute your Cassandra 6 migration with confidence.

Frequently Asked Questions