Why is it faster? Is it algorithmic, or some neat trick, or just a much more efficient implementation?
And are they closely equivalent? Would you use one or the other for the same thing, or do they make different CAP promises?
Scylla is written in C++ (versus Java for Cassandra) and uses the high-performance Seastar[0] framework.
> And are they closely equivalent? Would you use one or the other for the same thing, or do they make different CAP promises?
Scylla claims to be a drop-in replacement for Cassandra.
seastar -> sea star -> C* -> Cassandra ;)
Scylla has a highly optimized low-level I/O path that largely bypasses high-level OS APIs and kernel services that Cassandra and other open source databases tend to use. This will typically generate an integer factor improvement in I/O performance if implemented well and makes a big difference for the kinds of write-heavy workloads Cassandra was built for. It requires taking strict control of low-level memory access and behavior, which (for better and worse) is the default case in C++. This code is intrinsically non-portable.
Additionally, there are some important classes of throughput optimization that are incompatible with garbage collection. In principle you can abuse Java to effect these optimizations but it is much easier to implement these optimizations in languages that don't have a garbage collector. If absolute performance is the objective, like Scylla, it is easier to do the implementation in a language that won't fight your intent every step of the way.
tl;dr: The performance isn't so much that it is written in C++ but that C++ makes critical optimizations relatively straightforward and economic to implement.
Can you share some more details about these optimizations? I.e. what they are and why GC tends to go against them?
Performance is adequate for Cassandra, so the community has (for several years) primarily focused elsewhere. It will be a priority again in future, but in the meantime with many huge scale users out there the community has focused on guaranteeing correctness and stability at scale. For example, the Harry[1] toolkit for validating huge databases, and an adversarial cluster simulator[2] for exposing distributed and other complex bugs. Also a huge amount of behind-the-scenes work that isn't so easy to call out.
The community is now focusing on expanding the utility of the database for these use cases. For example the recently proposed enhancement to bring state-of-the-art general purpose transactions[3] to Apache Cassandra.
[1] https://github.com/apache/cassandra-harry
[2] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-10...
[3] https://cwiki.apache.org/confluence/download/attachments/188...
[edit] disclaimer: I’m an Apache Cassandra contributor involved with some of the above work.
Definitely newer JVMs are improving things such as latency, and there are now some that are NUMA-aware, but in a JVM you are literally straight-jacketed from seeing the raw hardware you are running on. And that will impact to greater or lesser degrees your ability to take advantage of it.
When operating a database at huge scale surprising things happen, because everything that can happen will happen. So operators are interested in ensuring the database behaves well in these extreme circumstances. This isn’t specifically about horizontal scalability, though that is a necessary component.
To your point about vertical scalability, no doubt Scylla performs better here. However the details of your mentioned comparison are perhaps misleading, as Cassandra can happily exploit more than 16vCPUs before its performance materially plateaus.
While it’s true that the JVM imposes some restrictions, they do not translate to a difference in performance on the order of that claimed in this post. JVMs have also been NUMA-aware for some time. The main explanatory factor is relative investment and focus.