Re: [DISCUSS] CEP-66: Zero-copy SSTable splitting

[Jeff Jirsa]

Indeed. It is exceptionally hard to run k8s without ebs. Possible but requires doing a lot of very unnatural things. Most of the planet is going towards containerized deployments for relatively obvious reasons.  It’s not something we should actively discourage.  On Oct 6, 2026, at 12:32 PM, Jon Haddad <j...@rustyrazorblade.com> wrote:  Agreed. Most teams I’ve worked with are on EBS. It’s significantly cheaper for denser storage. I’m running 15-20TB nodes. Ever since we merged CASSANDRA-15452, its worked really well.  Anyone using k8s is probably using EBS.  On Tue, Oct 6, 2026 at 12:20 PM Jeff Jirsa <jji...@gmail.com> wrote: > On Oct 6, 2026, at 4:49 AM, Benedict <bened...@apache.org> 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 <bened...@apache.org> 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.