On 11/1/2025 9:32 AM, Dinesh Joshi wrote:
On Fri, Oct 31, 2025 at 5:00 PM Patrick McFadin <[email protected]> wrote:Jeff and Dinesh jumped into Phase 2, which is really the fun and interesting part. To be clear, I am not proposing we make any changes pre Cassandra 6 in this case. And this will be a CEP or two or three.I was not intentionally trying to jump to Phase 2. I was trying to sus out the shape of what you were saying. I would like to think in terms of the user requirements to fully understand your proposal. IMO, SQL is a dialect that Cassandra can adopt and requires the right building blocks at the storage layer to work well. CQL should continue living alongside SQL and honestly we should not try to convert between those two unless there is a clear, well articulated reason for doing it. To be clear, I am not saying there is one. I am only keeping the door open for a constructive discussion around it if you or anybody else has one.
Conversion doesn't seem practical or desirable: it'd probably result in CQL and a muddled version of SQL which wouldn't be beneficial for anyone.
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.
Adopting SQL as kind of the "lingua franca" of declarative data access seems like a great way to increase adoption by giving new users an easier learning curve and maybe eventually making 3rd party integration (ORMs, drivers, etc.) easier. Let Cassandra's differentiating features shine.
The risk I see with pursuing SQL compatibility is striking the balance between preserving (or even strengthening) Cassandra's differentiating features -- huge scale, fast writes, tunable consistency, rich feature set -- without adding a bunch of gotcha's to its SQL support. For example, if the user needs to understand Cassandra's partitions and primary keys for optimal performance, then supporting arbitrary joins via SQL might lead less experienced users down a bad path. Is that an acceptable risk (as it seems to be for most RDBMSs), or something we'd want to put guardrails around, or just prevent outright (i.e., support the syntax, but constrain the semantics to prevent cluster-wide table scans, etc.)?
Does SQL support mean full syntax and semantic compatibility, or syntax compatibility with Cassandra-specific constraints on the semantics (so that Cassandra's key benefits aren't compromised)?
IMO, the user should pick a lane - CQL or SQL - when they create their Keyspace. This simplifies the implementation and descopes any potential conversion or compatibility related engineering effort.
+1. Thanks -- Joel.
