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. > > > >
