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. > On 4 Nov 2025, at 06:38, Mick <[email protected]> wrote: > > > >> 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.
