+1 I support this initiative. Also, I agree with the points raised by Joel.
- We should deprecate CQL in the long term over SQL. - Cassandra engine is not optimized with all the SQL features, such as joins, so we should disable those features. - I view this initiative as a way to slowly migrate CQL -> SQL rather than a standalone SQL, so I am looking forward to more detail. Jaydeep On Mon, Nov 3, 2025 at 11:32 AM Joel Shepherd <[email protected]> wrote: > 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. > > >
