Great question! If one decides to enable tablets and use default flexible placement mechanism/algorithm, it will pick the best possible fit for the tablet. Of course one can always override this or pick a custom tablet placement algorithm.
Tokens won’t become less pronounced for things like routing, streaming, or repair. The only place where this CEP moves from tokens will be the concept of a node owning a token and token ring derived replication. For simplicity I suppose it might be easier to say “repair tablet X” or “replace replica Y in tablet Z”, etc. But then, tablet is just a replicated range. On Mon, Mar 9, 2026, at 11:31 PM, Patrick McFadin wrote: > > Thanks, that helps. > > I agree that if tokens remain the underlying range coordinate system, then > CEP-57 is not immediately inconsistent with CEP-60. > > My question is about operators and migrations(my favorite topic). As clusters > move from classic token-derived placements to flexible placements, should > operators continue to think in token-bounded ranges, or do tokens become > mostly an internal detail, and the operational model shift to tablets or > table-specific placement units? > > Patrick > > > > On Mon, Mar 9, 2026 at 2:37 PM Alex Petrov <[email protected]> wrote: >> __ >> 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 >>>> >>
