Several more quotes that intersect between CEP-57 and CEP-60: from CEP-57: > To treat this problem we should allow users to specify a table’s atomicity > level, for example `partition`, `row` or `none`, and prevent splitting inside > the specified level.
While implementing flexible placements, we intend to allow tables belonging to the same keyspace to have ranges that are split between the nodes differently. Our understanding that this aligns well with CEP-57, since every table will likely have different partitions with hotspots in different places. CEP-60 will allow making split points at any point in the table, and things like repair and streaming for such split tables will just work out of the box. > Implementing a, or improving the existing, mechanisms of collecting load > statistics to form the input of automatic redistribution of data. There definitely will be some intersection here, since we are going to be collecting subrange metrics for load. CEP-60 does not include change-in-load-triggered automatic redistribution, since our intention was to limit the scope of CEP, but our ultimate goal does include auto-balancing. I have a separate document describing all metrics we'll be adding in detail. It was not included to CEP for scope reasons, but I will make sure to loop in CEP-57 authors once we start working on this. On Mon, Mar 9, 2026, at 11:54 PM, Alex Petrov wrote: > 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 >>>>> >>> >
