In short, CEP-60 doesn’t suggest we’re moving away from tokens. It adds an optional opportunity to allow placements to be decoupled from token ownership. In other words, owned range will still have start and end tokens, so I don’t see any inconsistency here.
I’d also like to highlight that anyone who prefers token ownership as a way of generation of placement maps, this will still be possible, and there are no plans or intentions for deprecating this. Does this clarify relation to CEP-57 for you? On Mon, Mar 9, 2026, at 10:09 PM, Patrick McFadin wrote: > > I do, actually. I finally got my head around CEP-60 and wanted to ask about > an inconsistency. Your proposal is trying to move away from tokens, but > CEP-57 requires them. From CEP-57: > > the key should be constructed as: ByteComparable.sequence(Token(X, Y), > Serialization(X, Y), A, B, C) > > How is this going to be reconciled? Stay on tokens or change CEP-57? > > Patrick > > On Sat, Mar 7, 2026 at 4:54 AM Alex Petrov <[email protected]> wrote: >> __ >> Thanks Jon! Very excited to be working on this. >> >> Since there has been not much discussion, and from conversations with some >> folks on slack and elsewhere it seems like we might be ready to move this to >> a vote. >> >> I will hold it off until Monday in case someone else had any thoughts. >> >> >> >> On Tue, Feb 24, 2026, at 10:57 PM, Jon Haddad wrote: >>> Alex, >>> >>> 12 years ago I filed CASSANDRA-8494 hoping someone much smarter than me >>> would take on the Herculean effort of completely reworking how we manage >>> our data. This CEP addresses my wish for incremental bootstrap and also >>> incorporates tablets, which have been on my radar for a long time. This >>> work will address some of Cassandra's biggest pain points today for >>> operators. >>> Thank you so much for this. I cannot overstate my enthusiasm for this CEP!! >>> >>> >>> Jon >>> >>> >>> On Tue, Feb 24, 2026 at 12:17 AM Alex Petrov <[email protected]> wrote: >>>> __ >>>> Hi everyone, >>>> >>>> We'd like to propose CEP-60: Flexible Placements [1] for adoption by the >>>> community. Building on CEP-21's Transactional Cluster Metadata [2], CEP-60 >>>> enables incremental, resumable operations, improved cluster density, and >>>> flexibility of data placements / ownership. >>>> >>>> CEP-60 benefits all users by further improving reliability of ownership >>>> operations. With flexible placements, clusters maintain near-optimal load >>>> balance at any size without explicit rebalancing phases. Ownership changes >>>> are broken into smaller sub-range steps that benefit from zero-copy >>>> streaming. >>>> >>>> CEP-60 is designed for incremental delivery: range-aware compaction, >>>> routing key abstractions, and metrics collection are useful on their own >>>> and will ship independently of the flexible placements feature. Existing >>>> token-based and vnode clusters will continue to work (while benefitting >>>> from incremental ops), and flexible placements can be enabled (and later >>>> disabled, if ever needed) on a per-keyspace basis. >>>> >>>> The CEP is linked here: >>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements >>>> >>>> Looking forward to the discussion of this CEP here on the dev list. >>>> >>>> Thanks! >>>> >>>> [1] >>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-60:+Flexible+Placements >>>> [2] >>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata >>
