I agree that new features should leverage SQL syntax. I can't think of a reason not to.
On Fri, Oct 31, 2025 at 5:00 PM Patrick McFadin <[email protected]> wrote: > I knew this would be a lot of information to try to convey. I swear it > sounded amazing in my head :D > > Let’s break up the Phase 1 and everything after it conversations. > > The Phase 1 part was in response to some recent discussions on current > CEPs. CEP-55( > https://lists.apache.org/thread/4swcf1n4qm7ps6g4brv2wnrql8n72p61) and > CEP-52(https://lists.apache.org/thread/8rcp808jb4y2jy2sttkhx0fv71qxnddf) > In those threads, the syntax for the changes would have been unique to CQL. > My suggestion was to just use the syntax for similar features in pgSQL. > Jyothsna is finishing up CEP-52 and the syntax is pgSQL and so anyone using > that new-to-Cassandra feature will find familiar syntax. > > In those threads, it was correctly pointed out that we don’t have any > agreed upon guidelines. My proposal with Phase 1 is just that. Any new > feature that is proposed, we defer to the pgsql format whenever possible. > And no, I'm not proposing we back port anything! (Not going there) > > I don’t think that is a CEP, however it does need some formality. Maybe a > VOTE thread and it’s just policy? > > > Jeff and Dinesh jumped into Phase 2, which is really the fun and > interesting part. To be clear, I am not proposing we make any changes pre > Cassandra 6 in this case. And this will be a CEP or two or three. > > To directly answer the questions and my first shot at imaging an > implementation in Phase 2, I think this is a matter of making > QueryProcessor[1] pluggable. I can’t take credit for this idea. It’s been > floated a few times, but in this case it might be the best place to start. > And to answer Jeff, this isn’t transforming CQL. I do think this is a new > implementation. > > Then possibly you could run both CQL and SQL at the same time. It’s just a > matter of what gets sent down to the storage engine. And then there is > CEP-39 [2] > > Jeff’s point about BOP is really interesting. And let’s not forget about > CEP-57 that was just proposed. The point being we have a lot of future > changes that, if everything is aligned, could come together is some > interesting ways. We have to agree on the directionality as a baseline. > It’s a strategy, not a plan. > > 1 - > https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/cql3/QueryProcessor.java > 2 - > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-39%3A+Cost+Based+Optimizer > 3 - > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-57%3A+Flat+keys+and+trie+interfaces > > On Oct 31, 2025, at 3:22 PM, Ekaterina Dimitrova <[email protected]> > wrote: > > Hey Patrick, > > Thanks for starting this discussion. > I am also curious to read the response to Dinesh’s questions. > > Plus I have one to add myself (potentially more after I spend more time on > this) - It is not clear to me what Phase 1 is. Do you suggest blocking 6.0 > alpha to review all new not yet released syntax to try to align it with > SQL? You plan to open a CEP and work on that? Or I misunderstood what you > suggest? > > Best regards, > Ekaterina > > On Fri, 31 Oct 2025 at 18:15, Dinesh Joshi <[email protected]> wrote: > >> Thank you Patrick for starting this thread. Your talk was interesting. I >> want to better understand the nature of compatibility aspect of what you're >> proposing. Specifically, how do you envision the following scenarios to be >> supported in this new world – >> >> 1. Could an operator enable CQL and SQL simultaneously? >> 2. Does the user need to pick CQL or SQL at the time of Keyspace creation >> or can they switch between CQL and SQL on the fly? >> 3. Would the user be able to read and write to the same Keyspace using >> both CQL and SQL? >> 4. Do you envision the user being able to write using CQL and read using >> SQL? >> >> Thanks, >> >> Dinesh >> >> On Fri, Oct 31, 2025 at 1:26 PM Patrick McFadin <[email protected]> >> wrote: >> >>> Over the last decade, CQL has served Cassandra users well by offering a >>> familiar SQL-like interface for a distributed data model. However, as the >>> broader database ecosystem converges on PostgreSQL-style SQL as the de >>> facto standard for developers, it’s time to consider how Cassandra evolves >>> to meet developers where they are without losing what makes it unique. >>> >>> The great thing about SQL standards is that there are plenty to choose >>> from. While the formal SQL:2023 specification (ISO/IEC 9075) exists, the >>> industry has coalesced around the PostgreSQL dialect. Products such as AWS >>> Aurora, AlloyDB, CockroachDB, YugabyteDB, and DuckDB, and many others >>> offering “PostgreSQL-compatible” modes, have validated this direction. >>> Developers are voting with their implementations. PostgreSQL SQL represents >>> the lowest cognitive-load interface for application data, as repeatedly >>> confirmed by developer surveys like Stack Overflow 2025[1]. >>> >>> What I’m proposing is that we begin to normalize the frontend to expand >>> access to our extraordinary backend. The key principle here is ADD, not >>> DELETE. CQL continues to work and be supported while we expand Cassandra’s >>> capabilities through SQL compatibility, providing a familiar syntax and >>> potentially supporting a larger ecosystem (JDBC, etc.). >>> >>> Phase 1 (Before Cassandra 6) - Stop Digging >>> Freeze CQL at version 3 and align all new syntax or features (DML/DDL) >>> to the PostgreSQL SQL dialect wherever possible. This approach was already >>> demonstrated with CEP-52 and should become our norm. >>> >>> Phase 2 (Years) - Create Parallel Paths >>> This is where we take our time and do things carefully, most likely over >>> a series of years. Don’t touch the CQL path. Add an opt-in, feature flag >>> path for SQL-only that conforms to the PostgreSQL SQL dialect. Begin our >>> journey to feature compatibility here. At Community over Code this year, >>> Alex Petrov and I sat in Aaron Ploetz’s kitchen (thanks for dinner, Aaron!) >>> and brainstormed how this could work. The two critical aspects to manage >>> are types and functionality. We may never be able to support everything, >>> but given what this project has accomplished over the years, I wouldn’t bet >>> on it. Being clear about the differences early on can serve as a roadmap >>> for future contributors who want to be involved. >>> >>> In discussion with Joel Shepherd on this topic, he sagely suggested some >>> sub-steps inside this phase: >>> >>> 1 - Prioritize SQL that is compatible to get the incremental wins and >>> early feedback from the user community. >>> 2 - Tackle the non-compatible and triage for the long-term changes that >>> would need to happen. >>> I took the time to do some rough mapping of syntax, features, and types: >>> >>> Function and Feature Compatibility tables: >>> https://docs.google.com/document/d/1K2-GKVM4Z_u1Hb1GtdrRyC9AdDN3RLwJ7LX_i_PqkOE/edit?usp=sharing >>> >>> Typing differences: >>> https://docs.google.com/spreadsheets/d/11tWkyCQ8WAFGnd5Va6iyltkp1wbKdAubxH9o_ZyJEtk/edit?usp=sharing >>> >>> Phase 3 (Indefinite timeframe)– Become Default SQL >>> Once the SQL path achieves sufficient coverage and confidence, we can >>> make it the default frontend, with CQL continuing to be supported >>> indefinitely. The intent is not replacement but evolution toward broader >>> accessibility. >>> >>> This proposal is an invitation for discussion. Feedback from >>> contributors, driver maintainers, and downstream users will guide the >>> roadmap and priorities. The result will be the creation of CEPs as needed. >>> If we get this right, Cassandra’s next decade will be defined by reach, >>> compatibility, and continued excellence in scalability. >>> >>> If you saw my talk in Minneapolis[2], you know I've been thinking about >>> what we can accomplish in 10 years. The Phase 1 piece is near-term, but no >>> timeframe for everything else. The best consensus I can hope for today is >>> on directionality, and that starts with phase 1. >>> >>> Patrick >>> >>> 1 - >>> https://survey.stackoverflow.co/2025/technology#most-popular-technologies-database-prof >>> 2 - https://youtu.be/rIh968dSlkQ >>> >> >
