Re: [DISCUSS] SQL support in Cassandra

[Jeff Jirsa]

CQL just to demonstrate it’s possible Fat node style would indeed be faster but im mostly proving that its functional On Nov 5, 2025, at 8:55 AM, Joseph Lynch <joe.e.ly...@gmail.com> wrote:  I very much like Jeff, Josh et al.'s proposals around the pluggable stateless API layer. Also I agree with Chris I would prefer a simpler API not a more complex one for our applications to couple to e.g. the Java stdlib. This also sets up a really nice path where the community members can build the layers that make sense first out-of-tree, and as a project we can choose the successful ones to bring in-tree. Whichever API those layers couple to would be a new semi-public interface though which has to be weighed. Jeff I am curious, in that prototype you are hacking are you interacting directly with the internode protocol and verb system or going through CQL? I imagine there could be some strengths to going straight to the internode? -Joey On Tue, Nov 4, 2025 at 3:49 PM Josh McKenzie <jmcken...@apache.org> wrote: Again from Right. I'm just zooming out a bit more and applying that same logical pattern broadly to other API language domains, not just SQL. But yes - your point definitely stands. On Tue, Nov 4, 2025, at 6:42 PM, Patrick McFadin wrote: I’m grooving on what “Cloud Native Jeff” is saying here and I would like to see where this could go. If we use a well established library like Calcite, then there is no API to maintain. We might find parts of Cassandra along the way we could alter to make it easier to integrate, but so far that’s just a premature optimization. Suuuuper interested to see the TPC-C when you have it, Jeff.  > On Nov 4, 2025, at 3:25 PM, Jeff Jirsa <jji...@apache.org> wrote: >  >  >  > On 2025/11/04 22:32:08 Josh McKenzie wrote: >>  >> So I guess what I'm noodling on here is a superset of what Patrick is w/a slight modification, where we double down on CQL as being the "low level high performance" API for C*, and have SQL and other APIs built on top of that. >>  >  > Again from https://lists.apache.org/thread/hdwf0g7pnnko7m84yxn87lybnlcdvn50 >  >> Or is it building a native SQL implementation stateless on top of a backing ordered (ByteOrderedPartitioner), transactional (accord), key-value cassandra cluster ? It’s an extra hop, but trying to adjust the existing grammar / DDL to fit into a language it always mimicked but never implemented faithfully feels like a bumpy road, where there are many successful existence proofs for building it stateless a layer above. >  > TiKV / TiDB, FoundationDB, etc, etc, etc. >  > If you have a transactional, performant, ordered KV store, you can built almost any high level database on top of it. You can expose even lower layer primitives (like placement) to optimize for it.