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] > <mailto:[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] >> <mailto:[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
