> On Oct 6, 2026, at 4:49 AM, Benedict <[email protected]> wrote:
>
>
>>
>> This feature primarily benefits a narrow and not recommended use case (EBS),
>> and our roadmap expects to obsolete it. The first draft increases the core
>> codebase size by around 1%, and more for later phases - this isn’t small.
>
> Sorry, in my edits for brevity I lost the point I was making here. Given the
> narrower benefit and lifetime of the feature, and non-trivial cost, we should
> try to see if we have alternatives that yield a stronger cost:benefit ratio.
>
> FWIW, I think cheap partial range streaming is an independently important
> thing we want to achieve, that is of long term benefit to the project - and I
> am not opposed to these other improvements in principle either.
>
>> On 6 Oct 2026, at 11:14, Benedict Elliott Smith <[email protected]> wrote:
>>
>> Hi Chris,
>>
>>> I think you would agree that complexity alone is not a reason to reject a
>>> design. You described Accord as “likely the most complex thing we have ever
>>> merged to the project,”
>>
>> Yes, we are discussing cost:benefit. Many proposals are subject to debate,
>> and I am sure you will recall that Accord was by no means exempted from this.
>>
>> This feature primarily benefits a narrow and not recommended use case (EBS),
>> and our roadmap expects to obsolete it. The first draft increases the core
>> codebase size by around 1%, and more for later phases - this isn’t small.
>>>
It’s not that narrow, and I dont know that I’d agree about it being
not-recommended (I personally put more than one company on it intentionally
despite the disk latency because of the cost and operational simplicity)
I’d bet most deployments of Cassandra are on disaggregated disks of some kind
(ebs, ceph, azure premium disks, etc).
Most local nvme offerings are ephemeral in cloud environments and much harder
to deal with operationally.
