On Mon, Dec 9, 2024 at 10:52 AM Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote:
> In the case of UCS, is it in a beta state until we resolve the discussions > around UX/documentation? From a functional and production usage > perspective, it has been the only compaction strategy available for users > in DataStax's Astra managed database service in both traditional node based > deployments and serverless for 5 years across thousands of databases. > I am sorry but I have seen instances where this argument was used and it is frankly puzzling to me. In my view, UCS' implementation inside Astra has little to do with the stability and production readiness of the code that is in Apache Cassandra. While its usage inside Astra is definitely a good data point, the code that is committed to Apache Cassandra and the way it integrates inside the open source code base could have different bugs / edge cases that do not appear in Astra. So I would really not be pointing at Astra as evidence of its robustness and maturity inside Apache Cassandra's codebase. > While I agree that it's premature to call that a new default for tables, > it seems overly cautious to me that it needs to pass through a beta > period. Let people opt into it and try it out and if something breaks, > let's fix it. I'm not sure of the value of using "beta" with it. > I am all for letting users try out new features in Cassandra but we're a database and we need to weigh risks carefully. Graduating a feature through different maturity and production readiness levels is very common and the rate at which they can move through different stages is directly related to the quantity and quality of testing they have been through. We can debate about the 'experimental' or 'beta' moniker but the goal is for the project to accurately inform the operator about the feature's production readiness so they can weigh the risk of enabling the feature for themselves. Thanks, Dinesh
