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