> conforming to one of the "standard" data APIs could make more people more > comfortable with staking their future on Cassandra Aligning with a standard data API could make people more comfortable staking their future, and deprecating a 2nd primary query language would *definitely* make people less comfortable staking their future on Cassandra too eh? :)
The tension we face here is very real and to your point: > worry about the long term cost of either maintaining parity across 2+ query > languages -- adding multi-language support for each new feature -- or > allowing the languages to diverge feature-wise. One leads to a lot of work, > the other leads to a lot of confusion If we try to 1st-class-citizen 2 different APIs we're going to always be balancing these 2 poles I think. And to Joey and some other points in the thread, we've long struggled to stabilize features that aren't natively good bedfellows with a leaderless architecture or our K/K/V wide-row storage engine, to the point where we haven't had the resources as a community to get some of them production ready to the level we need in years. Given that, I'm wary of us trying to take on supporting 2 poles like this long-term. A future where we 1) had a core rock solid CQL as primitive (language reflecting storage engine) and 2) had a translation layer that presented different APIs to different users for different use-cases could maybe give us the best of both worlds by creating a separation in our engineering efforts through architecture. Using Conway's Law for good, as it were. As that Storage Engine's capability grew (using "Storage Engine" kind of broadly here to encapsulate distributed query coordination too) with something like Accord, CQL itself would evolve and then the things we built on top of that could themselves then have richer API surface areas and better conformance with the totality of their respective language features. I'd think of this proposed model as "CQL is the deeper API layer to talk directly to C* and other language ecosystem support can be built on top of CQL". For any new language features in CQL going forward, defaulting towards SQL-compliance seems the logical choice rather than diverging further, all else being equal. Having a GraphQL API that supported the aspects of GraphQL that played nicely with CQL, or JSON, or ANSI SQL, each with their own specific restrictions or subset of implementation *seems* like it could give us the best of both worlds. I'm inclined to think that a layered architecture like that would be the best approach for both our users and ourselves maintaining the project, as well as growing the ecosystem. It would also be much easier to on-ramp as a contributor to work on a SQL implementation on top of CQL or a document API on top of it vs. needing to ramp on a less modularized, more coupled base single API like people have to do today. So I guess what I'm noodling on here is a superset of what Patrick is w/a slight modification, where we double down on CQL as being the "low level high performance" API for C*, and have SQL and other APIs built on top of that. On Tue, Nov 4, 2025, at 3:39 PM, Joel Shepherd wrote: > On 11/4/2025 11:42 AM, Patrick McFadin wrote: > > > > Just to be clear, in my initial proposal I said that CQL can never go > > away. It’s a life sentence. Knowing the upgrade cycle that many users > > are on, it will be 50 years before we could even try. > > Fifty years will go by like that. :-) > > I'd mostly worry about the long term cost of either maintaining parity > across 2+ query languages -- adding multi-language support for each new > feature -- or allowing the languages to diverge feature-wise. One leads > to a lot of work, the other leads to a lot of confusion. > > Thanks -- Joel. > > >
