> Why is it faster? Is it algorithmic, or some neat trick, or just a much more efficient implementation?

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.

0. http://seastar.io/

BTW, there is a word play here:

seastar -> sea star -> C* -> Cassandra ;)

The use of C++ enables a couple architectural optimizations that would be difficult or impractical in Java, aside from C++ generally producing significantly faster runtimes. The important difference is that C++ is a systems language -- you could replace C++ with Rust, Zig, etc -- whereas Java is not.

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.

In part it's also simply a demonstration of different priorities. Scylla's USP is performance, so a lot of elbow grease is spent there. The Apache Cassandra community is focused primarily on operating at scale, as that's its USP.

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.

The only clarification I want to make here is that Cassandra is focused on horizontal scalability, which Scylla can match. However, Cassandra isn't (now, or yet) focused on vertical scalability, such as using it in current instances that have dozens of vCPUs. This was shown in the "4 vs. 40" test of Scylla vs. Cassandra, where 4 boxes of a vertically scaled Scylla (72 vCPU each; 288 vCPUs total) were able to perform the same or better as 40 boxes of Cassandra (with 16 vCPU; 640 vCPU total).

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.

This is not what I was referring to, no.

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.

> there are some important classes of throughput optimization that are incompatible with garbage collection

Can you share some more details about these optimizations? I.e. what they are and why GC tends to go against them?

It appears to be a C++ rewrite of Cassandra (written in Java).

Similar vibe to redpanda vs. kafka: take a reasonable idea and reimplement it so it isn't terrible. https://vectorized.io/blog/fast-and-safe/

Yup, and redpanda happens to use Scylla's Seastar framework as well