Apache Cassandra 6.0 and Accord Transactions: What to Evaluate Before GA

Apache Cassandra 6.0 is the release that brings Accord, a general-purpose transaction protocol, into the database. For the first time, Cassandra users can update several partitions and tables atomically, with strictly serializable isolation, using ordinary CQL. It is the largest change to Cassandra’s consistency model in many years.

On the research date, 6.0 was still pre-release. Apache Cassandra 5.0 remains the latest generally available line. This article explains what Accord does, how it is enabled and used, its documented restrictions, the other 6.0 changes operators must prepare for, and how to plan evaluation before general availability.

Where Cassandra 6.0 stands

The Apache Cassandra downloads page listed these maintained server lines on the research date:

Line	Latest release	Status on the page
5.0	5.0.9 (7 August 2026)	Latest GA version; maintained until the 8.0 release
4.1	4.1.12 (7 August 2026)	Previous stable; maintained until the 7.0 release
4.0	4.0.21 (7 August 2026)	Older stable; maintained until the 6.0 release

The ASF release record for Cassandra 6.0-alpha1 shows an alpha with an effective date of 21 March 2026, followed by later end-of-distribution events. The downloads page did not list a 6.0 build. The project keeps a cassandra-6.0 branch in its repository, with release notes in NEWS.txt on the cassandra-6.0 branch.

Two practical points follow. Pre-release builds are for evaluation, not production. And teams still on 4.0 should note that its maintenance ends when 6.0 is released, so a move to 4.1 or 5.0 is due now regardless of Accord.

What Accord is designed to do

Accord comes from the CEP-15 General Purpose Transactions proposal. Its motivation is familiar to anyone who has modelled data for Cassandra. Multi-partition changes needed application-level coordination, and packing related state into one partition does not scale. Lightweight transactions, built on Paxos, cover single-partition conditions only.

The proposal’s goals include:

• transactions over any set of keys in the database, with conditions on any of them;
• strict-serializable isolation;
• a leaderless protocol, so any node can coordinate a transaction, with no central bottleneck;
• continued progress when a minority of replicas fail;
• live migration from Paxos, which the proposal expects Accord to replace for the project over time.

The CEP lists transactional global secondary indexes and non-global modes as future goals, not part of the initial work. Accord makes cross-partition correctness possible; it does not remove the need for good partition design.

Enabling Accord and writing transactions

The Cassandra 6.0 transactions documentation describes two settings. Accord is enabled in cassandra.yaml:

accord: enabled: true

Each table then has a transactional_mode:

Mode	Behaviour	Documentation’s guidance
off	Default. No Accord support; lightweight transactions use Paxos.	Existing behaviour
mixed_reads	Mixes transactional and non-transactional access during a transition	Not recommended for most users
full	All reads and writes go through Accord; ordinary reads and writes become linearizable	Recommended

With full, ordinary CQL statements run through Accord automatically. Explicit transaction blocks are for multi-step, multi-partition or multi-table logic. A simplified example from the documentation’s pattern:

BEGIN TRANSACTION LET acct = (SELECT balance FROM accounts WHERE id = ?); IF acct.balance >= ? THEN UPDATE accounts SET balance = balance - ? WHERE id = ?; END IF COMMIT TRANSACTION

LET reads one row into a variable, and IF blocks hold conditional changes. A LET query must return exactly one row and fully specify the partition key with equality. Computed values should be passed in as parameters, because row-reference arithmetic in SET clauses is not supported. Syntax in pre-release documentation can change before general availability.

Restrictions and design trade-offs

The documentation lists what transaction blocks cannot contain:

• counter tables or counter operations;
• aggregates, ORDER BY or GROUP BY;
• custom TTLs or timestamps, since the transaction manages timestamps;
• range deletes;
• non-equality partition key restrictions in LET or SELECT;
• per-statement conditions, which are replaced by transaction-level IF blocks.

These limits reflect the design: the set of keys a transaction touches must be known when it is submitted. Transactions are one-shot units, not interactive sessions that read, think and write across round trips.

Coordination also has a cost. The documentation notes that cross-partition transactions add overhead, and it suggests keeping the number of LET reads and partitions per transaction small as a starting point. In practice:

• Use transactions for invariants that span partitions, such as balances, inventory or uniqueness across tables.
• Keep high-volume, append-style writes outside transactions where eventual consistency is acceptable.
• Measure latency and throughput on your own topology, especially across datacenters, before committing a design.
• Plan how existing lightweight-transaction code will move, since Paxos and Accord coexist during a transition.

Accord compared with today’s options

Most Cassandra applications already enforce some cross-row rules. The question is whether Accord should replace the current mechanism. The table compares the common approaches, based on the CEP-15 proposal and the 6.0 transactions documentation:

Approach	Scope	Trade-offs
Data model in one partition	Related state packed into a single partition	No coordination needed, but partitions grow and hot spots appear. The CEP notes this does not scale.
Lightweight transactions (Paxos)	Conditional writes within one partition	Familiar and available on all maintained lines. Cannot express conditions across partitions.
Application-level coordination	Any keys, through locks, queues or compensating writes	Flexible, but correctness lives in application code and is hard to test under failure.
Accord transactions (6.0)	Any keys and tables, with strictly serializable isolation	Correctness moves into the database. Requires 6.0, table mode changes and acceptance of documented restrictions.

The CEP also states that batches on transactional tables, including unconditional ones, receive ACID properties, and that conditional batches spanning partitions become valid. That can simplify code that today relies on logged batches and retries.

The strongest early candidates are invariants that are expensive to get wrong and currently enforced with fragile application logic. Workloads already well served by a single-partition model gain little, and should stay as they are until the new path is proven in your environment.

Other 6.0 changes operators must prepare for

The 6.0 release notes list several changes that affect operations even if Accord is never used:

• Transactional Cluster Metadata (CEP-21). A distributed log linearises changes to membership, token ownership and schema. After all nodes run the new version, operators must run nodetool cms initialize. Until then, schema changes, bootstrap, decommission, node replacement and moves are not permitted. The notes advise against making every node a Cluster Metadata Service member, and state the minimum safe size is three nodes.
• Automated repair (CEP-37). A built-in scheduler orchestrates repair inside Cassandra, which can replace external repair tooling. Existing repair runbooks need review, not just deletion.
• JDK 21. JDK 21 is officially supported, and generational ZGC becomes the default collector on it.
• Constraints framework (CEP-42). Table-level constraints can reject invalid client data.
• Configuration changes. native_transport_port_ssl is removed in favour of a single port. IEndpointSnitch is deprecated, with its responsibilities split into new interfaces, though endpoint_snitch remains supported for now. trickle_fsync now defaults to true, and a guardrail set to zero now means zero rather than unlimited.

The CMS initialisation step is the one most likely to surprise an upgrade plan. It turns a rolling binary upgrade into a two-phase change, with a window in which topology and schema are frozen.

An evaluation plan for the pre-release period

The pre-release window is the cheapest time to learn how Accord and the new metadata service behave in your environment. Findings reported now can still shape the release.

1. Move any 4.0 clusters to 4.1 or 5.0 on the current patch release.
2. List the invariants your applications enforce across partitions today, and how.
3. Build a test cluster from the 6.0 branch or an available pre-release, matching production topology and datacenters.
4. Rehearse the upgrade, including nodetool cms initialize and the metadata freeze window.
5. Enable Accord on copies of selected tables in full mode, and port one or two invariants into transaction blocks.
6. Run failure tests: node loss, datacenter partition and restarts during transactions.
7. Measure the cost of transactions against your current approach, using your own workload.
8. Review repair, garbage-collection and port configuration changes against existing runbooks.
9. Report defects to the project, and decide adoption only after general availability and early patch releases.

How Bassirah can help

We help teams plan Cassandra upgrades, rehearse Cluster Metadata Service initialisation, and test whether Accord transactions suit their data models. This is independent engineering under our Apache Cassandra support; upstream fixes follow the project’s timeline, as our support model explains. For multi-datacenter designs, see our telecom distributed analytics architecture.