I hope that we avoid building a client if we use something like Calcite. That would give us access to that client library set: https://calcite.apache.org/avatica/docs/
In the previous thread, there was a discussion of future changes to Cassandra and how SQL could leverage them. (See CEP-57) The Primary Key definition is the most essential aspect of CQL and directly ties to our storage engine and the use of a random partitioner. Random partitioning has made it almost impossible to implement global indexes and range scans over keys. Because this has been an age-old issue, there have been ideas on how best to use ByteOrderedPartitioner for those use cases. BOP just has too many sharp edges, and it's rarely used in production. This future-looking discussion of adding a SQL layer nicely coincides with the discussion of partitioning changes. Combined, I think we might have a path forward and avoid that awkward forcing SQL on top of CQL-optimized storage. Even JOIN is on the table. (Why BOP has been so tempting for years) Patrick On Thu, Nov 6, 2025 at 7:53 AM Jindal, Himanshu <[email protected]> wrote: > Hi Patrick, > > Thanks for putting this together. > > I had a question about how the client landscape might evolve in a world > where we introduce a new SQL port alongside the existing CQL port. Would > this require us to build a dedicated SQL client, or could existing SQL > applications and drivers connect to Cassandra with minimal changes? > > Even setting aside syntactical differences (like lack of JOINs), I’m > curious whether the underlying differences in partitioning and routing > would inherently require a specialized Cassandra client. If that’s the > case, do we risk losing some of the benefits we hope to gain from adding a > SQL port in the first place? > > Thanks again for driving this discussion. > > Best, > Himanshu > > > *From: *Patrick McFadin <[email protected]> > *Date: *Wednesday, November 5, 2025 at 1:28 PM > *To: *dev <[email protected]> > *Subject: *[EXTERNAL] [DISCUSS] Bringing SQL to Cassandra > > *CAUTION*: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > This is a fork of the longer discussion that happened here: > https://lists.apache.org/thread/f1q2pfpglp6d49ysoy2bvq1f5vh9bod5 > > There were some great ideas presented about bringing SQL to Cassandra. > Thanks for ChatGPT, here is a summary of the main ideas: > > - CQL stays. No deprecation. CQL remains the high-throughput, low-level > API indefinitely. > - SQL should be implemented as a stateless layer on top of the storage > engine, not by reshaping CQL into SQL. > - Utilize storage alignment with future engine work. Accord > (transactions) + ByteOrderedPartitioner / CEP-57 (ordered keyspace) make > the SQL layer more robust. > - Form a SIG / Working Group to define scope, gaps, prototypes, and > guardrails. > > Finally, everyone is waiting to see how well the prototype Jeff Jira is > building works. > > Let's pick it up from here! > > Patrick >
