Not recommended means we do not recommend it, and do not provide guidance for deploying on it. If you believe we *should* recommend EBS we can have that discussion. My view is that a lot of decisions in the database make little sense in this deployment, and should be revisited to support it as a first class deployment option - and somebody needs to do that work. At minimum we need dedicated guidance before considering it one of our supported deployments.
Either way, while this was the motivation, the alternative option’s downside is not really a problem on EBS, so it actually only strengthens the case for pursuing it. On 2026/10/06 19:46:42 Jeff Jirsa wrote: > 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 <[email protected]> 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 > > <[[email protected]](mailto:[email protected])> wrote: > > > > > > >> > > > > > On Oct 6, 2026, at 4:49 AM, Benedict > > <[[email protected]](mailto:[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]](mailto:[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. > >
