If you’re operating Apache Cassandra, one of the leading distributed NoSQL databases, understanding the end-of-support schedule for each version is crucial for maintaining a secure and stable production environment. With the release of Cassandra 5.0 in September 2024 and the official end-of-life for the 3.x series, many organizations are now reviewing their upgrade strategies. This comprehensive guide covers the detailed EOS/EOL schedule for all Apache Cassandra versions and extended support policies from major cloud providers.

1. Understanding Apache Cassandra Support Policy Fundamentals

Apache Cassandra follows a policy of supporting the latest three releases simultaneously. This is relatively generous compared to other open-source projects and is designed to accommodate stable operations in enterprise environments.

Core Support Policy Principles

• Compatibility Maintenance: Ensures compatibility between adjacent major versions
• Zero-Downtime Upgrades: Supports online upgrades from one major version to the next
• Patch Releases: Regular patch releases for security vulnerabilities and critical bug fixes

2. Currently Supported Cassandra Versions

As of September 2024, the officially supported Apache Cassandra versions are:

Detailed Patch Version Information

Cassandra 5.0.x Series:

• 5.0.0 (2024-09-05) – GA release
• 5.0.1 (2024-11-08) – Latest stable version

Cassandra 4.1.x Series:

• 4.1.0 (2022-07-13) – Initial release
• 4.1.1 (2022-10-03) – Bug fixes
• 4.1.2 (2023-02-23) – Security updates
• 4.1.3 (2023-05-10) – Stability improvements
• 4.1.4 (2023-11-01) – CVE response
• 4.1.5 (2024-02-12) – Performance optimization
• 4.1.6 (2024-04-15) – Bug fixes
• 4.1.7 (2024-06-20) – Security patches
• 4.1.8 (2024-08-14) – Stability improvements
• 4.1.9 (2024-11-05) – Latest patch version

Cassandra 4.0.x Series:

• 4.0.0 (2021-07-26) – GA release
• 4.0.1 (2021-09-30) – Initial bug fixes
• 4.0.2 (2021-12-14) – Stability improvements
• 4.0.3 (2022-02-11) – Security updates
• 4.0.4 (2022-05-17) – Performance improvements
• 4.0.5 (2022-08-29) – Bug fixes
• 4.0.6 (2022-10-03) – CVE response
• 4.0.7 (2022-10-23) – Stability enhancements
• 4.0.8 (2023-02-23) – Security patches
• 4.0.9 (2023-05-10) – Bug fixes
• 4.0.10 (2023-08-18) – Performance optimization
• 4.0.11 (2023-11-01) – CVE response
• 4.0.12 (2024-02-12) – Stability improvements
• 4.0.13 (2024-04-15) – Bug fixes
• 4.0.14 (2024-06-20) – Security updates
• 4.0.15 (2024-08-14) – Performance improvements
• 4.0.16 (2024-09-30) – Stability enhancements
• 4.0.17 (2024-10-25) – Bug fixes
• 4.0.18 (2024-11-05) – Latest patch version

3. Complete End-of-Life Version Schedule

Complete Apache Cassandra Version History and EOL Status

Here’s a comprehensive overview of all major versions released throughout Apache Cassandra’s history:

3.x Series Detailed Patch Information

Cassandra 3.11.x Series (EOL: September 2024):

Cassandra 3.0.x Series (EOL: September 2024):

Legacy Versions (Historical)

Cassandra 2.2.x Series:

• Initial release: August 12, 2014
• Final version: 2.2.19 (estimated 2017)
• Key features: JSON support, User-Defined Types (UDT), improved compression

Cassandra 2.1.x Series:

• Initial release: January 9, 2014
• Final version: 2.1.22 (estimated 2016)
• Key features: Incremental repair, user-defined functions

Cassandra 2.0.x Series:

• Initial release: September 3, 2013
• Final version: 2.0.17 (estimated 2015)
• Key features: Full CQL3 support, lightweight transactions (LWT)

Cassandra 1.x Series:

• 1.2.x: October 2012 ~ 2014 (final: 1.2.19)
• 1.1.x: April 2012 ~ 2013 (final: 1.1.12)
• 1.0.x: October 2011 ~ 2012 (final: 1.0.12) – First stable release

4. Extended Support Policies by Cloud Providers and Commercial Distributions

After official support ends, several cloud providers and commercial distributions offer extended support for specific versions.

Extended Support Policies by Major Cloud Providers

DataStax Enterprise (DSE) Support Policy

DataStax Enterprise is a commercial distribution based on Apache Cassandra with separate support policies:

DSE Support Policy Explanation:

• EOL (End of Life): General technical support ends
• EOSL (End of Service Life): Extended support also ends completely

Microsoft Azure – Cosmos DB for Cassandra

Support Content:

• CVE patch application
• Production issue-related bug fixes
• Turnkey in-place major version upgrade support
• Migration support through hybrid cluster configuration

Migration Path:

• Existing self-hosting → Azure Managed Instance
• Gradual migration through hybrid clusters
• Automated backup and recovery systems

NetApp Instaclustr Extended Support

Support Conditions:

• Available for managed platform customers
• Priority given to Enterprise Support customers
• Includes security patches and critical bug fixes
• Maintains 24/7 production SLA support

Upgrade Paths:

• Cassandra 3.11.19 → 4.0.17+ direct upgrade
• Cassandra 3.11.19 → 4.1.8+ direct upgrade
• Future upgrade support to 5.0

AWS Amazon Keyspaces Migration Option

Amazon Keyspaces is a fully managed serverless database service compatible with Apache Cassandra:

Key Features:

• CQL API compatible with Cassandra 3.11.2
• Serverless architecture with automatic scaling
• Migration support for existing Cassandra applications
• Native AWS security and monitoring integration

Migration Tools:

• cqlsh COPY commands
• AWS Database Migration Service
• Cassandra Migration Toolkit

Other Commercial Support Options

5. Version-Specific Features and Upgrade Compatibility Matrix

Complete Version Upgrade Compatibility Matrix

The following table shows upgrade compatibility between Apache Cassandra versions:

Upgrade Rules:

• ✅ Direct Upgrade: Can upgrade directly
• ❌ Not Supported: Upgrades that skip major versions are not supported
• ❌ Downgrade: Downgrades to lower versions are not officially supported

JVM Compatibility Matrix

Supported Java versions for each Cassandra version:

Operating System Support Matrix

Detailed Analysis of Revolutionary Features by Version

Cassandra 5.0.x – Next-Generation Features

🔥 Core New Features:

Cassandra 4.1.x – Operational Excellence Innovation

🛠️ Major Improvements:

Cassandra 4.0.x – Stability Milestone

⚡ Core Features:

Historical Significance of Legacy Versions

Cassandra 3.11.x (EOL)

Important final 3.x version:

• Last version with full Java 8 support
• Most widely used in stable production environments
• Standard version in many enterprise environments

Cassandra 3.0.x (EOL)

Beginning of a new era:

• Introduction of Materialized Views (later deprecated)
• New storage engine (SSTable 3.0 format)
• Expanded JSON support

Cassandra 2.x Series (EOL)

Recommended Versions by Production Environment

6. Detailed Upgrade Strategy and Migration Checklist

Customized Upgrade Strategies by Version

3.11.x → 4.0.x Upgrade (Most Common)

Phase 1: Pre-Upgrade Preparation

Phase 2: Rolling Upgrade Execution

# Example node-by-node sequential upgrade script
#!/bin/bash

# 1. Check current node status
nodetool status

# 2. Drain the node
nodetool drain

# 3. Stop Cassandra service
sudo systemctl stop cassandra

# 4. Upgrade package
sudo yum update cassandra -y  # RHEL/CentOS
# or
sudo apt update && sudo apt upgrade cassandra  # Ubuntu/Debian

# 5. Review and adjust configuration files
sudo vim /etc/cassandra/cassandra.yaml

# 6. Restart service
sudo systemctl start cassandra

# 7. Check node status
nodetool status
nodetool info

# 8. Wait for stability before proceeding to next node
sleep 300  # 5-minute wait

Phase 3: Post-Upgrade Validation

3.0.x → 4.1.x Upgrade (2-Phase Upgrade)

Recommended Path: 3.0.x → 4.0.x → 4.1.x

4.x → 5.0.x Upgrade (Latest Features)

Special Considerations:

• JDK 17 mandatory requirement
• SAI index migration planning
• Vector data type usage review

JDK Upgrade Checklist:

Upgrade Strategies by Cluster Size

Small Clusters (3-6 nodes)

Recommended Method: Sequential rolling upgrade

• Duration: 2-4 hours
• Downtime: None (if RF ≥ 2)
• Risk Level: Low

Medium Clusters (7-20 nodes)

Recommended Method: Rack-by-rack rolling upgrade

• Duration: 6-12 hours
• Downtime: None
• Parallel Processing: One node per rack

Large Clusters (21+ nodes)

Recommended Method: Data center-by-data center phased upgrade

• Duration: 1-3 days
• Risk Management: Independent progression by DC
• Traffic Distribution: Utilize load balancers

Rollback Procedures for Failed Upgrades

Automated Rollback Script

#!/bin/bash
# Emergency rollback script

ROLLBACK_VERSION="3.11.19"
BACKUP_CONFIG="/opt/cassandra-backup/config"

echo "=== Emergency Rollback Started ==="

# 1. Stop service
sudo systemctl stop cassandra

# 2. Install previous version package
sudo yum downgrade cassandra-${ROLLBACK_VERSION} -y

# 3. Restore configuration files
sudo cp ${BACKUP_CONFIG}/cassandra.yaml /etc/cassandra/

# 4. Verify data directory permissions
sudo chown -R cassandra:cassandra /var/lib/cassandra

# 5. Restart service
sudo systemctl start cassandra

# 6. Check status
sleep 30
nodetool status

echo "=== Rollback Complete ==="

Upgrade Monitoring Checklist

Real-Time Monitoring Metrics

Performance Benchmark Comparison

Pre/Post-Upgrade Performance Measurement

# Pre-upgrade performance baseline measurement
cassandra-stress write n=1000000 \
  -rate threads=50 \
  -node 192.168.1.10,192.168.1.11,192.168.1.12

# Post-upgrade performance verification
cassandra-stress read n=1000000 \
  -rate threads=50 \
  -node 192.168.1.10,192.168.1.11,192.168.1.12

# Mixed workload testing
cassandra-stress mixed ratio\(write=1,read=3\) n=1000000 \
  -rate threads=50 \
  -node 192.168.1.10,192.168.1.11,192.168.1.12

Data Integrity Verification Procedures

Upgrade Project Timeline

Overall Project Schedule (3.11 → 4.1 Upgrade Example)

Organizational Roles and Responsibilities for Upgrades

7. Risks of Delaying Upgrades and Security Considerations

Security Vulnerability Exposure

Continuing to use versions that have reached end-of-life poses several risks:

• Unpatched CVEs: No security patches for new vulnerabilities
• Compliance Issues: Potential violation of enterprise security policies
• Technical Debt Accumulation: Increasing upgrade complexity over time

Performance and Stability Issues

• Lost Optimization Opportunities: Missing performance improvements in newer versions
• Hardware Compatibility: Potential compatibility issues with modern hardware
• Reduced Community Support: Decreased technical support and troubleshooting assistance

With the official end-of-support for the Apache Cassandra 3.x series, many organizations are at a decision point regarding upgrades.

Immediate Action Required:

• Currently using 3.x versions in production environments
• Environments where security compliance is critical
• Projects requiring latest features

Phased Approach Possible:

• Can utilize extended support from cloud providers
• Low external exposure risk as internal systems
• Sufficient time to establish comprehensive migration plans

Most importantly, don’t delay. Technical debt grows over time, and upgrade complexity increases. Now is the perfect opportunity to leverage Cassandra’s latest features and advance your system to the next level. 🙂

Related Links:

• Apache Cassandra Official Site
• Cassandra 5.0 Release Notes
• Official EOL Announcement
• EndOfLife.date – Cassandra