I think the opposite, and that CQL is the only reason people still adopt Cassandra today. Remember Thrift, which started by using terms like columns and rows for completely different concepts and went downhill from there? I felt it was a very interesting choice to have CQL only capable of expressing queries that Cassandra could perform quickly. It forced people to adjust their data models immediately, rather than defer the problem until the performance issues got too deep to ignore. Its a different mindset to relational databases, for different sorts of problems. If only they had used the same sort of restraint on other features attempting to make Cassandra do things it is unsuitable for, such as 'transactions' and counters, which are just an embarrassment of problems.

You missed the point - both SQL & CQL are declarative languages.

>> CQL does not even have SQL SELECT.

https://docs.datastax.com/en/cql/3.1/cql/cql_reference/selec...

This sure looks a lot like SQL SELECT. It returns a projection of data. Beyond that it's just pedantry.

Not supporting WHERE, GROUP BY, all aggregate functions, almost all other "standard" functions, most forms of DISTINCT, ORDER BY (except one order defined at table create time), all forms of sub-select/CTEs, etc. is pedantry?

OK. :)

It's not just a subset, but there are also incompatibilities like limit limits the number of rows scanned not the number of rows returned.