You are touching on the reason we are here today talking about this topic. I (and probably a few others still active on this list) were there before CQL. In a nutshell here's our API journey:
Thrift Thrift with external schema definition (schema.xml) - CQL started and died for a while: https://lists.apache.org/thread/87hsdd0gxo22fw8qkbpsj3xygbkmx5w0 Thrift with internal schema definition CQL 1 - First shot at not thrift. Thread: https://lists.apache.org/thread/vgpscfj13dbg0823d62bb07j2ksmz124 Jira: https://issues.apache.org/jira/browse/CASSANDRA-1703 CQL 2 - It was short lived. I don't remember much other than it was abandoned quickly for... CQL 3 - And where we are today: https://issues.apache.org/jira/browse/CASSANDRA-3761. CQL 3 has a continuously updated definition file. https://cassandra.apache.org/doc/trunk/cassandra/developing/cql/index.html However, you won't find any formal specifications for the language's design. AFAIK, that was left up to the feature creator. 13 years later, that's mostly what I'm proposing. A guideline for feature developers. Patrick On Thu, Nov 6, 2025 at 7:59 AM Jindal, Himanshu <[email protected]> wrote: > 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 >
