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 >> >
