Is the best path there really trying to transform CQL into SQL? Or is it building a native SQL implementation stateless on top of a backing ordered (ByteOrderedPartitioner), transactional (accord), key-value cassandra cluster ? It’s an extra hop, but trying to adjust the existing grammar / DDL to fit into a language it always mimicked but never implemented faithfully feels like a bumpy road, where there are many successful existence proofs for building it stateless a layer above.
> On Oct 31, 2025, at 1:25 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
