My intuition is that we would still compare quite favorably to almost all other API ecosystems even w/a routing layer gap, our core strength being a clean, horizontally scaling, partitioned data store. If we introduced a 1-3ms overhead (shooting for an artificially high # here) from using API -> CQL in an API gateway hop for instance (instead of writing to internode + verbs), but could still scale horizontally and have the durability characteristics we have now, the benefit from having that functionality loosely coupled might justify the cost. We could probably have a layer like that be much, *much* faster than 1-3ms w/a more modern runtime env (even just newer JDK and clean-room impl).
And for the record, we could offer API -> CQL -> Storage Engine from an endpoint on C* nodes; no absolute need for another layer hop. Just my first thought was "What kind of performance expectations do people used to JSON, SQL, REST, GraphQL have?". Alternatively, formalizing "internode + verb" as an API with a documented expectation for those "fat clients" in the ecosystem to be consumers of that internode lower level API instead (which is the follow-on question that popped up for me from your question Joey). So instead of [API -> CQL -> Storage Engine] it'd be [API -> Storage Engine], and CQL would be one implementation among many. We'd take a hit on flexibility in how we architect and work at that internode + verb layer if it became a public API w/all the evolution and deprecation pains that come from that, but I don't *think* we've been super mutable in that space over the years. Super interesting work Jeff. I'm sure I'm one person among many who are now *super curious* about what you've been working on. On Wed, Nov 5, 2025, at 12:15 PM, Jeff Jirsa wrote: > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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. >>>> >>>> >>>
