> On 3 Nov 2025, at 20:32, Joel Shepherd <[email protected]> wrote:
>
> At the same time, my personal opinion is that if SQL compatibility is
> pursued, then the end game should be to deprecate CQL. That will probably
> take years, but at the limit I don't see a lot of benefit to supporting both.
We want SQL, but _why_ (in all its nuances) do we want SQL ? A lot is obvious,
but it is a very broad question.
The adoption and standardisation benefits are obvious, but CQL has strengths
relative to SQL in Cassandra’s context.
One is Cassandra’s wide-partition model with flexible clustering columns, which
supports very large, ordered partitions (e.g. time-series and efficient range
scans), rather than a strictly normalised, join-centric model. These patterns
don’t always map cleanly to SQL semantics, and CQL’s query-driven,
table-per-query modelling helps move users toward designs that scale
predictably.
I can see CQL continuing as Cassandra’s high-throughput, query-driven DSL,
while we pursue SQL compatibility. I appreciate Dinesh’s ‘lanes’ framing, e.g.
eventually default to a SQL interface (with Accord) for the broadest UX, while
CQL remains a high-throughput path.
Should we also be discussing storage-engine implications ? Cassandra’s
LSMT/SSTable design optimises write paths; while a SQL presents a logical view
without constraining physical layout; so data on disk stays optimised for
dominant access patterns. I can also see the need to discuss transport vs
query languages differences.
Are we after both SQL's DML and DDL abilities ? Beyond accessibility and
exploration, SQL often comes with mature tooling for schema change management.
Cassandra supports online schema changes (e.g., ALTER TABLE), but
cross-table/primary-key changes remain constrained. A SQL interface alone won’t
‘solve’ this: it’s about migration tooling and engine capabilities; changing
data models at-scale faces separate challenges.
Especially outside of early-stage apps and ad-hoc exploration I find SQL less
interesting and its ergonomics less aligned with Cassandra’s runtime
performance model. That doesn't make me opposed to the endeavour of SQL
compatibility, it pushes me on the why question a bit more for alignment
clarity to our strengths.
