Cassandra 5.0 AWS CPU Requirements: Graviton4, ZGC, and Performance Optimization

What’s New in 2025

Key Updates and Changes

• Cassandra 5.0: Enhanced CPU utilization with improved compaction and streaming
• Graviton4 Processors: 40% better performance for database workloads
• ZGC Integration: Low-latency garbage collection for improved response times
• Instance Types: New I8g, R8g, C8g families optimized for Cassandra workloads
• Compaction Improvements: Better concurrent compactor defaults and tuning

Major Performance Enhancements

• Unified Compaction: Reduced CPU overhead in Cassandra 5.0
• Vector Search: CPU-intensive operations requiring additional cores
• Streaming Performance: Improved parallel processing for data migration
• Memory Management: Better allocation strategies reducing CPU pressure
• ARM Optimization: Native ARM64 support for Graviton processors

Cassandra 5.0 CPU Requirements in AWS Cloud

Cassandra 5.0 is highly concurrent and can utilize as many CPU cores as available when configured correctly. Understanding CPU requirements is crucial for optimal performance on AWS EC2 instances.

Continue reading

Cassandra 5.0 AWS Storage Requirements: GP3, I4g Instances, and Performance Optimization

What’s New in 2025

Key Updates and Changes

• EBS GP3 Volumes: 20% cost savings over GP2 with independent IOPS/throughput scaling
• I4g Instances: Graviton2-powered with 30TB NVMe, 15% better compute performance
• I4i vs I4g: 45-60% lower cost per TB with Im4gn/Is4gen families
• Unified Compaction: Cassandra 5.0 reduces storage overhead and improves I/O patterns
• EBS Optimization: Enhanced throughput up to 80 Gbps on latest instance types

Storage Performance Improvements

• GP3 Baseline: 3,000 IOPS and 125 MiB/s regardless of volume size
• GP3 Maximum: Up to 16,000 IOPS and 1,000 MiB/s (4x faster than GP2 max)
• NVMe Performance: I4g delivers up to 7.6 million IOPS per instance
• EBS Elastic Volumes: Live migration between volume types without downtime
• Storage Classes: New archive and deep archive tiers for long-term retention

Cassandra 5.0 AWS Storage Requirements

Cassandra 5.0 performs extensive sequential disk I/O for commit logs and SSTable writes, while requiring random I/O for read operations. The enhanced Unified Compaction strategy in Cassandra 5.0 provides more predictable I/O patterns and reduced storage overhead.

Continue reading

Cassandra AWS CPU Guidelines

Cassandra CPU requirements in AWS Cloud

Cassandra is highly concurrent. Cassandra nodes can uses as many CPU cores as available if configured correctly.

What are vCPUs and ECUs?

An Amazon EC2 vCPU is a hyper thread, often referred to as a virtual core. Think of it as a physical thread of execution. It is able to run one thread at a time (which of course could be swapped out).

An Amazon ECU is some made up term that AWS used to use which was the power of the Intel Pentium chip that they used on the earliest incarnations of EC2. 50 ECU would be like 50 Pentium chips from a bygone era. Ignore ECUs.

Continue reading

Cassandra AWS Storage Requirements

Cassandra AWS Storage Requirements

Cassandra does a lot sequential disk IO for the commit log and writing out SSTable. You still need random I/O for read operations. The more read operations that are cache misses, the more your EBS volumes need IOPS.

Cassandra writes to four areas

• commit logs
• SSTable
• an index file
• a bloom filter

Consider EC2 instance store instead of EBS for Cassandra

AWS provides EC2 instance local storage called instance storage which is not available with all EC2 instance types, and Elastic Block Store (EBS). Instance storage does not have to go over a SAN or Intranet, instead it uses the local hardware bus. Instance storage is right there on the server you are renting. The downside of EC2 instance storage is the expense, and it is not as flexible as EBS. Due to historic problems with EBS, it used to be the only real option for running Cassandra in AWS. EBS has a reputation for degrading performance over time. Some of this has likely been fixed with enhanced EBS, but instance storage is more reliable.

Continue reading

Notes on Cassandra OS setup and optimizations for deploying in EC2/AWS

Notes on Cassandra OS setup and optimizations for deploying in EC2/AWS

Disk concerns

These are important concepts for developers and DevOps who are responsible for developing Cassandra based applications and services.

Cassandra writes to four areas

• commit logs
• SSTable
• an index file
• a bloom filter

The compaction process of SSTable data makes heavy use of the disk. LeveledCompactionStrategy may need 10 to 20% overhead. SizeTieredCompactionStrategy worse case is 50% overhead needed to perform compaction. Keep this in mind while sizing disks. If you are doing a high-update use case, LeveledCompactionStrategy is the best solution if you want to limit the total disk size used at any point in time and to optimize reads as the row will be spread across less (up to ten times less) SSTables. LeveledCompactionStrategy requires more IO and processing time for compactions. If in doubt, use LeveledCompactionStrategy.

Continue reading