+1 to Mick and Aleksey. I think the key for me was this:
I think that would give us a future state of "Use SQL when you need / want a lot of expressivity, use CQL when you need to be constrained to language primitives that keep your data access scalable". The part that gets me wary here is how we've run into pain in the past trying to be both a database that allows more query expressivity (ALLOW FILTERING, legacy 2i come to mind) and a database that also wants horizontal scale.
I'd love us to be able to have our cake and eat it too but I don't know if that's possible. So at the very least I'd advocate for SQL + CQL going forward, or SQL + a constrained "CQL-like" mode that gives the same constraints CQL does today on modeling that guide people towards that very partitionable path.
I don’t mind us implementing some Postgres syntax support in some capacity, but I do not like the idea of limiting what Cassandra is allowed to do, or expose via CQL, to what is expressible by Postgres’s SQL.
Many moons ago, before we started work on native protocol and CQL, I could perhaps a bigger benefit to going Postgres route - for the client protocol and the language. We could piggyback on existing client infrastructure and SQL familiarity. But at this stage, when we have already made the effort to develop decent drivers, and CQL is fleshed out, and C* is quite mature overall, how much would we gain from this transition?
I’m broadly with Mick here. And I support using Postgres’ SQL as inspiration for implementing new CQL features wherever it makes sense - it’s something we’ve been doing for a decade already. But I don’t believe that deprecating CQL is the way to go at this point.
>
>
>
>>
>> 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.
