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
