Hi Patrick, This makes sense to me. My understanding has been that CQL was introduced to make Cassandra more approachable — giving users a familiar, SQL-like interface while preserving Cassandra’s underlying data model. From my experience, that familiarity has played a big role in Cassandra’s adoption, so continuing to build on it feels like the right direction.
One request: would it be possible to look through the archives and capture the original intent behind CQL’s design? It will be valuable to formalize those principles in the codebase itself — perhaps as README files or design notes. CEPs and mailing list discussions can fade over time, but documentation that lives with the code tends to persist and guide future contributors more effectively. Thanks again for leading this conversation. Best, Himanshu From: Patrick McFadin <[email protected]> Date: Wednesday, November 5, 2025 at 11:18 AM To: dev <[email protected]> Subject: [EXTERNAL] [DISCUSS] The future of CQL syntax CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. This is a focused discussion stream to contemplate future CQL syntax as we add new features. Succinctly, I proposed to ratify the use of SQL syntax when possible when adding new features. Prior work demonstrating that this can be successful is CEP-52. Needed to add labels to schema, took the previously art in PostgreSQL and used it. This is NOT a proposal to backport or retrofit syntax. What is already in CQL is a part of the spec. The separate topic of adding full SQL support will be in a different DISCUSS thread. The guidance for new feature developers would be: - Review existing SQL syntax for your feature - If there are extraordinary reasons to now use SQL syntax, enumerate them in the CEP - Performance and correctness take precedence. Patrick
