FWIW, I expect to push my demo/poc next week (unless I'm surprised by something before then).
Transparently, it will require ~1 or 2 fixes to accord for variable sized keys, and it slows down otherwise because accord journals dont merge cleanly. I fixed one version of this bug, but not all of them, so TPC-C is slower than I want (and it's not worth talking about the total benchmark). Up to about 20,000 rows, reads are about 3-5ms with SQL, and writes are about 5-10ms, a read that has to do a full table scan on a 100k row table was 500ms. So about 2-5x the latency you'd expect from native cassandra or postgres, with basically no attempt to optimize (not even doing prepared statements or query caching or literally anything other than very naive implementation), but I believe based on the model it should scale horizontally approximately like you'd expect from cassandra (modulo row level contention). On 2025/11/05 21:26:12 Patrick McFadin wrote: > 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 >
