Hacker News Reader

Comment by AtlasBarfed | Hacker News Reader

Not sure why you would use it over Cassandra, which scylladb last I checked was a C++ rewrite that had impressive initial feature releases but has since lagged in feature support badly.

I would migrate to cassandra first, and then prototype your workloads on scylladb. You'll want loadtest execution ability regardless so you can tune for your workloads.

I'd guess ScyllaDB and Cassandra are comparable for headaches. Our clusters never go down, but there's always SOMETHING to look at. But cassandra has more community and commercial support.

View on HN

1. Performance https://www.scylladb.com/2021/08/24/apache-cassandra-4-0-vs-...

2. Features https://www.scylladb.com/2021/11/17/cassandra-and-scylladb-s...

ScyllaDB used to chase Cassandra's feature set. Now, in many ways [MV, compaction strategies, workload prioritization, LWT, CDC] we can either do things Cassandra cannot do, or we're a better implementation of Cassandra's same or similar functionality.

Cassandra c. 2018-2020 was a pretty moribund project, not shipping a major new release until last year [2021]. I am pretty excited to see the new work done on 4.0 and now 4.1. During the same interval ScyllaDB went from 2.0 to now 5.0 which is coming out Very Soon Now.

The CEP process Cassandra maintains shows some very interesting directions they are heading in. And we showed off some of our roadmap at Scylla Summit 2022 describing where we're taking our product next.

Whichever path users decide, the good news is that year-over-year users have increasingly better databases to choose from.

[Disclosure: I work at ScyllaDB.]

Re: your comparison, LWTs in Cassandra in 4.1 (about to release) offer global 1RT reads, and 2RT for writes. Your comparison suggests you take 3RTs? I suspect you may be moving to offering 1RT for those in the local region, and 2RT for all operations in another region?

You make a point of mentioning your MVs (and presumably your global secondary indexes) may get out of sync with the base table, which is the reason the Cassandra community decided to mark them experimental. The Cassandra community has become very conservative since it began being driven by users of the software. I should not draw any conclusions around the relative merits of features from this conservatism.

The Cassandra community paused feature development for several years, due to this very conservatism, in order to focus on delivering safety and reliability at scale. Now that's done, you can expect a lot more visible activity.

There will definitely be a lot of jostling as Cassandra gets ahead here, and ScyllaDB there. Yes, we've talked about our plans to get to 1RT LWTs.

And you are totally correct to point out that there are needs for conservatism in people running at scale. Hence why we recently released making our Enterprise offering available as either a short term feature release or a long-term support release.

The MV issues have been hardened in ScyllaDB so the likelihood of them getting out of sync are minimized. And we're implementing Raft into the architecture to make them even more consistent with the base table. [Not available yet, but part of our roadmap.]

I believe that when you get to 1RT, your LWTs will still effectively be 2RT if you include the coordinator's latency to the leader (except in the leader's region).

Reply on news.ycombinator.com