🤩 (utterly speechless)
> On 15 Nov 2025, at 00:26, [email protected] wrote: > > I’ve uploaded a demo / proof of concept to show people how close we are to > being able to implement something that looks a lot like SQL on Cassandra. The > repository link is at the bottom, but first a few notes. > > 1) This is not for production. Even if it looks like it works, don’t use it. > This is to demonstrate for you all fine Cassandra developers where we are in > terms of ability. > 2) The reason it feels worth doing this right now is that the combination of > TCM and Accord makes it possible for us to think about data models in > Cassandra that are closer to those we’d implement on a transactional > key-value store, using wide-partitions ONLY for versions of > byte-order-comparable keys, instead of using it for the data model itself. > Before transactional cluster metadata, you wouldn’t want to deal with the > range splitting. Before accord, you wouldn’t be able to write to enough > partition keys to make this viable. > 3) This is all AI written. The code and the docs. This isn’t lovingly > handcrafted artisanal for-loops. This is about 99% AI. It’s amazing what AI > coding assistants can do in 2025. Highly recommended. They kept trying to > promise this is production ready (it’s not), and they don’t know Accord > syntax, though (training date cutoff, I guess), and the two I used struggled > to deal with inferring the grammar from the ANTLR and test files in the > Cassandra repo. Which means it’s sorta maybe optimized to minimize silly > transactions, but it’s not that optimized. For example, there’s a global > timestamp oracle that has its own incrementer in an accord transaction, and > there’s a sequence generator for auto-incrementing primary keys in its own > transaction, and the percolator-light prewrite/promotion logic with pre-write > locks and copy to the main table in its own transaction, and we could > certainly make that one if we tried hard enough, but I didnt. > 4) I’ve tried, in most places, to make it safe to run N of these stateless > apps in isolation, using Cassandra itself for shared state. In theory, if we > wanted to do something like this for real, we should be able to run many of > them, and come up with a better way to do the timestamp oracle. Most of the > other implementations in this space run that oracle on one leader elected > process which limits the cluster’s overall size and throughput, and I tried > NOT to do that, but you can definitely see the impact in the latency. > 5) Cassandra has a few gaps that still make this not great. Accord + BOP keys > aren’t playing nicely together. There’s no reverse range scans. There’s also > a really suspect token() block in DataRange for SAI/2I that I just dont > understand and it’s prepending a weird (token() <=) conditional to range > scans that I strongly suspect is wrong for BOP (but I’m not sure). > 6) If we do this in real life, I’m not at all convinced that Java is the > right solution. On the plus side, stuff like Calcite exists and is easy, and > we can skip CQL and go straight to fat-client internode. On the minus side, > it’s 2025 and other languages exist that are faster and dont have the GC > problems. > > The repo is here: > https://github.com/geico/cassandra-sql > > > A demo of what it can do is here: > > https://github.com/geico/cassandra-sql/blob/main/demo-ecommerce.sh > > > (If you dont want to test it yourself, that file runs in about 5-6s on my > laptop, if you’re curious about the speed/latency). > > The basic architecture is here: > https://github.com/geico/cassandra-sql/blob/main/docs/ARCHITECTURE.md > The implemented grammar is here: > https://github.com/geico/cassandra-sql/blob/main/docs/SQL_GRAMMAR.md > > > I don’t expect this to be the jumping off point for implementing a project > like this, but it can be if everyone wants it to be. I really just hope to > point out that the current state of Cassandra makes real, proper SQL much > closer than many people probably expected it to be. > > > - Jeff > > >> On Nov 7, 2025, at 11:00 AM, Jeff Jirsa <[email protected]> wrote: >> >> 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 >>> >
