Why 14 Teams Moved on from Apache Cassandra
Tags: database, opensource, nosql, cassandra
Published: 2022-03-17 21:39:26

At first glance, it’s easy to understand the attraction to Apache Cassandra. There’s support for massive amounts of data. Horizontal scalability. High availability. No single point of failure. Seamless replication. The simplicity of CQL. With personality traits like that, it’s not surprising that Cassandra has been one of the most popular databases since its release just over a decade ago – or that it’s still used by the massive teams at companies like Apple, Uber, Netflix, and Spotify.

However, there’s not always a fairy tale ending. When the honeymoon is over and reality sets in, some teams find that Cassandra is not a match made in heaven for their particular use case or resources.

Rather than continue a database relationship that wasn’t working out, many teams decided to move on. They explored their options. And they found new Cassandra database alternatives that gave them what they loved most about Cassandra… without the incompatibilities that were troubling them, and with many additional benefits as well.

Here’s a quick look at some of their stories:

## Comcast
Comcast hit Cassandra’s capacity for their Xfinity X1 Platform, which serves billions of API calls per day while processing over 25 million independent scheduled calculations. Migrating off of Cassandra gave them 10x improvement in latency, enabled them to handle 2x the requests at <5% of the cost, and provided an extreme node reduction (962 to 78). [Watch **[Comcast on Sprinting from Cassandra to ScyllaDB](https://www.scylladb.com/tech-talk/sprinting-from-cassandra-to-scylladb/)**]

## Fanatics
Fanatics, official retailer of virtually every major sports league and event, faced Cassandra struggles such as node sprawl, frequent garbage collection (GC) pauses, and CPU spikes during compactions — and this led to timeouts. By moving on from Cassandra, they cut 55 nodes to 6, reduced EC2 costs by 80%, and now experience smooth and error-free performance even in their bursty traffic environment. They also alleviated database maintenance pains. [Read/watch **[Fanatics: Using Scylla for Online Order Capture](https://www.scylladb.com/2020/01/23/fanatics-using-scylla-for-online-order-capture/)**]

## Expedia
Expedia faced 4 main challenges with Cassandra: Garbage Collection, burst traffic, infrastructure costs, and infrequent releases. By replacing Cassandra, they are achieving 3x throughput vs. Cassandra at single-digit read latencies as well as 30% infrastructure cost savings. [Read/watch **[Expedia Group: Our Migration Journey to ScyllaDB](https://www.scylladb.com/2021/02/18/expedia-group-our-migration-journey-to-scylla/)**]

## Rakuten
Patience with Cassandra’s volatile latencies was wearing thin at Rakuten, a global online retailer with 1.5B worldwide members. They faced JVM issues, long Garbage Collection pauses, and timeouts – plus they learned the hard way that a single slow node can bring down the entire cluster. So they left Cassandra. The payoff: 5-6x performance improvement, better total cost of ownership (going from 24 nodes to 6), and predictably low latencies that enable impressive SLAs. [Watch **[Rakuten’s Catalog Platform Migration from Cassandra to ScyllaDB](https://www.scylladb.com/presentations/rakutens-catalog-platform-migration-from-cassandra-to-scylladb/)**]

## Natura
Natura, the multibillion-dollar Brazilian cosmetics company behind brands such as Avon and The Body Shop, was looking to leave Cassandra’s JVM and the associated performance issues behind. By doing so, they reduced their P95 write latencies from 220 milliseconds to 500 microseconds They also reduced hardware costs by over 50%. [Read/watch **[Natura’s Short and Straight Road from Cassandra to ScyllaDB](https://www.scylladb.com/tech-talk/naturas-short-and-straight-road-from-cassandra-to-scylla/)**]

## Samsung Ads / Adgear
AdGear, a leading advertising platform, previously used Cassandra for its bidding gateway service. However, delays beyond the 10-15 millisecond bidding window caused lost business. After moving on to a new database, their effective read latency at peak traffic fell from 21 ms on 31 nodes to 13 ms on 13 nodes – plus, latencies became much more stable over the course of the day. [Read/watch **[AdGear and ScyllaDB at the Big Data Montreal Meetup](https://www.scylladb.com/2018/08/02/adgear-scylladb-big-data-meetup/)**]

## GumGum
GumGum, a global contextual intelligence company, used Cassandra for years. However, as the business grew, load and capacity constraints emerged, they ended up spending valuable engineering time managing Cassandra clusters. Migrating to a fully-managed Database as a Service (DBaaS) freed up 20% of two people’s time, reduced their cluster size from 51 to 30 nodes, and produced higher throughput with better performance. [Read/watch **[Contextual Ads: Scylla at GumGum](https://www.scylladb.com/2021/06/15/contextual-ads-scylla-at-gumgum/)**]

## Kiwi.com
Business was taking off at Kiwi.com, a popular flight booking service, but Cassandra proved unable to scale. They experienced CPU overload and massive latency spikes even as they added more and more nodes. Once they replaced Cassandra, they never looked back. Cassandra required 100 nodes to achieve 40K reads per second. Now, with only 21 nodes, they could achieve 900K reads per second – at 25% of the cost. [Read/watch **[Kiwi.com Takes Flight on ScyllaDB](https://www.scylladb.com/2019/07/30/kiwi-com-takes-flight-on-scylla/)**]

## FullContact
Cassandra didn’t live up to the expectations of FullContact, a privacy-safe Identity Resolution company. Cassandra promised scalability, high availability, and low latency on commodity hardware, but it couldn’t run their internal workloads as fast as their business required. By moving on to a new database, they could push through 7X the number of queries per second while dropping the 98th percentile latency from 2 seconds to 15 milliseconds. [Read **[FullContact: Improving the Graph by Transitioning to ScyllaDB](https://www.scylladb.com/2021/04/15/fullcontact-improving-the-graph-by-transitioning-to-scylla/)**]

## Steelhouse / MNTN
For 7 years, television ad leader Steelhouse (now MNTN) relied on Cassandra clusters that habitually generated reams of timeouts and prevented them from maintaining the expected timeout SLA. They moved on, and their new database easily handles the ~9B requests interacting with their backend at any given time. They eliminated painful timeouts and achieved a roughly 20% improvement in team productivity by eliminating Cassandra maintenance. [Read **[SteelHouse: How Our Real-Time Switchover from Cassandra to Scylla Saved the Day](https://www.scylladb.com/2019/05/13/steelhouse-how-our-real-time-switchover-from-cassandra-to-scylla-saved-the-day/)**]

## Opera
In their years of working with Cassandra, web browser maker Opera faced constant issues including enormous load, Cassandra processes being killed, and many GC-related issues that required hundreds of hours to debug. Now, with a new database, their on-call engineers can finally get enough sleep. They no longer have to babysit their database 24/7. It just simply works as promised, and the developers at Opera can focus on creating new features instead of repairing Cassandra. [Read **[Opera Syncs Tens of Millions of Browsers with ScyllaDB](https://www.scylladb.com/2019/06/18/opera-syncs-tens-of-millions-of-browsers-with-scylla/)**]

## Ticketmaster
Ticketmaster was seeking a more predictable database that could handle their brief-but-massive on-sale traffic spikes without batting an eyelash. They found a solution that was more stable than Cassandra as well as more suitable for their extreme traffic demands. [Watch **[Ticketmaster Performance Test: Scylla, DataStax DSE and Apache Cassandra](https://www.scylladb.com/tech-talk/ticketmaster-performance-test-scylla-datastax-dse-and-apache-cassandra/)**]

## Dstillery
Dstillery, a leading custom audience solutions provider, needs to be able to read and write at scale to the tune of hundreds of billions of requests a day with a timeout of 25 milliseconds. No matter how many nodes they added to the Cassandra cluster, they could not lower the failure rate below 0.1% (which amounts to thousands of failures). By replacing their database, they lowered the error rate to nearly 0.0% and freed themselves from having to tune ~40 different settings for garbage collection, JVM, memtables, compaction, and cache sizes. [Read **[Q&A with Dstillery’s Hang Chan](https://www.scylladb.com/2019/06/11/qa-with-dstillerys-hang-chan/)**]

## OpenNMS
When architecting a time-series database embedded within their monitoring platform, the team behind the OpenNMS network monitoring platform originally turned to Cassandra. However, these embedded databases quickly and substantially grow by ingesting a constant stream of events and metrics from a variety of sources. They found that Cassandra couldn’t scale to deliver high performance with the steady stream of growth. But with an underlying storage layer database swap, they achieve 1.8X throughput. [Read/watch **[OpenNMS Newts: A Time-Series Database for Network Monitoring, Built on ScyllaDB](https://www.scylladb.com/2019/07/25/opennms-newts-a-time-series-database-for-network-monitoring-built-on-scylla/)**]

## Is Your Team Thinking about Moving on From Cassandra?
We encourage you to learn more about the [similarities and differences between ScyllaDB and Apache Cassandra](https://www.scylladb.com/2021/11/17/cassandra-and-scylladb-similarities-and-differences/) and to review (or even replicate, if you wish) the [Cassandra vs ScyllaDB performance benchmark](https://www.scylladb.com/2021/08/24/apache-cassandra-4-0-vs-scylla-4-4-comparing-performance/). And if you’re considering a switch, our Solution Architects can [help you determine](https://www.scylladb.com/product/technical-consultation/) if you and your team might be happier with a different database, like [ScyllaDB](https://www.scylladb.com/product/technology/).