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