CQL is more than sugar , although it was originally created to encourage people to migrate from the SQL world. The world before CQL was useless, dozens of clients written differently using the Thrift protocol, but unlike the SQL Cassandra world, everyone improves every day, introducing new features in each version, and very often each of these improvements requires a new “client version” capable of processing a new kind of generated results (for example, think of counters or collections) or a new syntax for using a new function.
I am glad that I had the opportunity to go into production for more than 3 years with the help of the Thrift client (Pelops) - this helped me understand a lot of the world of cassandra, data structure, etc. - but now I will never return to such a client (although it was really great!).
In the beginning, Kassandra was completely different, in particular, it was / had
“ no schema ” means that each CF row may contain a different number of columns, and there was no place where these columns should have been declared. This led to disasters of many projects, the ability to add new columns in "runtime" led to a situation where you did not know what you could find in the table.
super-columns obsolete data structure replaced by wide rows
Now that the data model is stable, the CQL syntax provides greater readability, and now you can go to any project that you are not so familiar with the ability to understand how the application talks to the database thanks to its unique syntax - - every new release of Cassandra immediately follows a new client version.
CQL is not a "subset" of SQL, as many people write: it is somehow a "superset" because it is able to process different data structures, expanding the base language.
My answer: think with a key, but use CQL ONLY
NTN, Carlo