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
