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.

 

Apache Cassandra

 

 

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:

Major Version Release Date Support Status Latest Patch Version Key Features
5.0.x September 5, 2024 Currently Supported 5.0.1 Vector Search, SAI, Trie SSTables, JDK 17
4.1.x July 13, 2022 Currently Supported 4.1.9 Management simplification, enhanced security, new encryption
4.0.x July 26, 2021 Currently Supported 4.0.18 Fast streaming, incremental repair, audit logging

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:

Major Version Initial Release Final Patch Version EOL Date Support Status Key Features
5.0.x 2024-09-05 5.0.1 Currently Supported Vector Search, SAI, Trie structures
4.1.x 2022-07-13 4.1.9 Currently Supported Management simplification, security enhancements
4.0.x 2021-07-26 4.0.18 Currently Supported Virtual Tables, audit logging
3.11.x 2017-06-23 3.11.19 September 2024 EOL Improved streaming, compression optimization
3.0.x 2015-11-09 3.0.32 September 2024 EOL New storage engine, materialized views
2.2.x 2014-08-12 2.2.19 ~2017 EOL JSON support, user-defined types
2.1.x 2014-01-09 2.1.22 ~2016 EOL Performance improvements, new token allocation
2.0.x 2013-09-03 2.0.17 ~2015 EOL CQL3, lightweight transactions
1.2.x 2012-10-16 1.2.19 ~2014 EOL Row-level isolation, performance improvements
1.1.x 2012-04-24 1.1.12 ~2013 EOL Self-tuning, compression improvements
1.0.x 2011-10-17 1.0.12 ~2012 EOL First stable release
0.x 2010-02-17 0.8.10 ~2011 EOL Early development versions

3.x Series Detailed Patch Information

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

Patch Version Release Date Major Changes
3.11.0 2017-06-23 Initial release
3.11.1 2017-10-11 Initial bug fixes
3.11.2 2018-02-12 Performance improvements
3.11.3 2018-06-18 Security updates
3.11.4 2019-02-11 Stability enhancements
3.11.5 2019-10-06 Bug fixes
3.11.6 2020-02-13 CVE response
3.11.7 2020-07-20 Performance optimization
3.11.8 2020-08-26 Security patches
3.11.9 2020-10-05 Stability improvements
3.11.10 2021-02-08 Critical bug fixes
3.11.11 2021-07-26 Security enhancements
3.11.12 2021-10-05 Performance improvements
3.11.13 2022-02-21 CVE response
3.11.14 2022-10-23 Stability updates
3.11.15 2023-02-23 Security patches
3.11.16 2023-05-10 Bug fixes
3.11.17 2023-11-01 CVE-2023-43642 response
3.11.18 2024-02-12 Final security update
3.11.19 2024-09-05 Final release (EOL)

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

Patch Version Release Date Major Changes
3.0.0 2015-11-09 Initial release
3.0.1 2015-12-23 Initial bug fixes
3.0.2 2016-01-19 Performance improvements
3.0.28 2022-10-23 Stability updates
3.0.29 2023-02-23 Security patches
3.0.30 2023-05-10 Bug fixes
3.0.31 2023-11-01 CVE response
3.0.32 2024-09-05 Final release (EOL)

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

Provider Supported Version Extended Support Period Support Content Requirements
Microsoft Azure Cassandra 3.11 Until end of 2024 CVE patches, production bug fixes, in-place upgrades Azure Managed Instance for Cassandra
NetApp Instaclustr Cassandra 3.x Until September 2025 (12-month extension) Security patches, critical bug fixes, Enterprise support Instaclustr Managed Platform customers
Amazon AWS Cassandra 3.11 Limited support Migration support via Keyspaces service Amazon Keyspaces migration
Google Cloud Cassandra 4.x Standard support GKE-based Cassandra operations support Google Cloud deployment

DataStax Enterprise (DSE) Support Policy

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

DSE Version Based on Cassandra Release Date EOL Date EOSL Date Support Status
7.0.x Cassandra 4.0+ 2023 Currently Supported TBD Currently Supported
6.8.x Cassandra 3.11+ 2019-07-23 2024-07-31 2025-01-31 ⚠️ Extended Support
6.7.x Cassandra 3.11 2018-12-05 2022-05-31 2022-11-30 End of Support
6.0.x Cassandra 3.0 2018-04-17 2022-05-31 2022-11-30 End of Support
5.0.x Cassandra 2.1 2016-06-28 2018-12-05 2019-06-05 End of Support
4.8.x Cassandra 2.1 2015-09-23 2018-04-16 2018-10-16 End of Support

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:

Other Commercial Support Options

Provider Service Name Supported Versions Features
Aiven Aiven for Cassandra 4.0, 4.1 Multi-cloud support, automated backups
ScyllaDB ScyllaDB Cloud Compatible API C++ rewrite, high-performance alternative
Elastic Elastic Cloud Cassandra connector Elasticsearch integration solution

 

 

5. Version-Specific Features and Upgrade Compatibility Matrix

Complete Version Upgrade Compatibility Matrix

The following table shows upgrade compatibility between Apache Cassandra versions:

Current Version → Target Version 3.0.x 3.11.x 4.0.x 4.1.x 5.0.x Upgrade Type
3.0.x ✅ Patch ✅ Direct ✅ Direct ✅ Direct ❌ Not Supported Online possible
3.11.x ❌ Downgrade ✅ Patch ✅ Direct ✅ Direct ❌ Not Supported Online possible
4.0.x ❌ Downgrade ❌ Downgrade ✅ Patch ✅ Direct ✅ Direct Online possible
4.1.x ❌ Downgrade ❌ Downgrade ❌ Downgrade ✅ Patch ✅ Direct Online possible
5.0.x ❌ Downgrade ❌ Downgrade ❌ Downgrade ❌ Downgrade ✅ Patch Online possible

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:

Cassandra Version Java 8 Java 11 Java 17 Java 21 Recommended Version
5.0.x Recommended Java 17
4.1.x Recommended Java 11
4.0.x Recommended Java 8/11
3.11.x Recommended ⚠️ Experimental Java 8
3.0.x Recommended Java 8

Operating System Support Matrix

Operating System 3.0.x 3.11.x 4.0.x 4.1.x 5.0.x
Linux (RHEL/CentOS 7+)
Linux (Ubuntu 18.04+)
Linux (Debian 9+)
Windows Server ⚠️ Limited ⚠️ Limited
macOS (Development)

Detailed Analysis of Revolutionary Features by Version

Cassandra 5.0.x – Next-Generation Features

🔥 Core New Features:

Feature Name Description Technical Advantages Use Cases
Storage Attached Indexes (SAI) High-performance indexing replacing Secondary Indexes Dramatically improved memory efficiency, enhanced query performance Complex filtering, range queries
Vector Search Vector similarity search for AI/ML Vector data type support, similarity functions Recommendation systems, image/voice search
Trie Memtables/SSTables Trie-based memory/storage structures 40% reduction in memory usage, improved I/O performance Large-scale data processing
JDK 17 Support Latest Java runtime support Performance improvements, latest security features Modern infrastructure
Unified Compaction Strategy Unified compaction strategy Optimized read/write performance balance Mixed workloads
Dynamic Data Masking Dynamic data masking GDPR/privacy compliance Privacy protection

Cassandra 4.1.x – Operational Excellence Innovation

🛠️ Major Improvements:

Feature Area Improvements Practical Benefits
Configuration Management YAML validation, dynamic configuration changes Prevents operational errors, zero-downtime configuration changes
Security Enhancements New encryption options, FIPS 140-2 support Meets enterprise security requirements
Monitoring Enhanced metrics, extended virtual tables Significantly improved operational visibility
Networking Compression improvements, streaming optimization Network bandwidth savings

Cassandra 4.0.x – Stability Milestone

⚡ Core Features:

Feature Name Technical Details Performance Impact
Incremental Repair Progressive repair mechanism 90% reduction in repair time
Virtual Tables Query system metadata via CQL Enhanced monitoring and debugging efficiency
Audit Logging Comprehensive audit logging Security auditing and compliance
Zero Copy Streaming Zero-copy streaming 3x faster inter-node data transfer

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)

Version Revolutionary Features Historical Significance
2.2.x JSON support, UDT (User-Defined Types) Bridge between NoSQL and relational databases
2.1.x User Defined Functions, incremental repair Introduction of developer-friendly features
2.0.x CQL3, Lightweight Transactions Completion of modern query language

Recommended Versions by Production Environment

Environment Type Recommended Version Reason
New Projects 5.0.x Latest features, long-term support guaranteed
Stable Existing Operations 4.1.x Proven stability, sufficient features
Legacy Migration 4.0.x Safe upgrade path from 3.x
AI/ML Workloads 5.0.x Vector Search essential
Financial/Healthcare 4.1.x Strict audit and security requirements

 

 

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

Item Details Estimated Time
Compatibility Verification Test application CQL queries 1-2 weeks
JVM Upgrade Java 8 → Java 11 migration 3-5 days
Configuration Review Verify cassandra.yaml compatibility 2-3 days
Backup Execution Create full cluster snapshots 4-8 hours
Test Environment Setup Replicate production environment 1 week

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

Validation Item Verification Method Expected Result
Cluster Status nodetool status All nodes UN (Up Normal)
Data Consistency nodetool repair No consistency issues
Performance Testing Run cassandra-stress Achieve baseline performance
Application Testing Full functional testing All features working normally

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:

Step Task Notes
1 Verify current JVM version java -version
2 Install JDK 17 OpenJDK recommended
3 Update JAVA_HOME environment variable Modify /etc/environment
4 Review GC options Consider G1GC or ZGC
5 Readjust heap size Reflect new GC characteristics

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

Metric Normal Range Alert Threshold Tools
CPU Usage < 70% > 85% htop, Grafana
Memory Usage < 80% > 90% nodetool info
Disk I/O < 80% > 95% iostat
Network Throughput Normal level Sudden changes iftop
GC Pause < 100ms > 500ms gc.log
Read/Write Latency < 10ms > 50ms nodetool proxyhistograms

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

Verification Step Command Expected Result
1. Schema Verification DESCRIBE TABLES; All tables normal
2. Data Count SELECT COUNT(*) FROM table; Same as pre-upgrade
3. Consistency Check nodetool repair No inconsistencies
4. Replication Verification nodetool status All nodes synchronized
5. Backup Verification nodetool snapshot Snapshots created normally

Upgrade Project Timeline

Overall Project Schedule (3.11 → 4.1 Upgrade Example)

Week Phase Key Activities Deliverables
1-2 Planning Current state analysis, risk assessment Upgrade plan document
3-4 Environment Preparation Test environment setup, tool preparation Test environment
5-6 Testing Compatibility testing, performance testing Test report
7 Final Preparation Backup, checklist verification Ready for execution
8 Production Upgrade Rolling upgrade execution Upgrade complete
9 Stabilization Monitoring, performance optimization Stabilization report

Organizational Roles and Responsibilities for Upgrades

Role Responsibility Area Key Tasks
DBA Team Database operations Backup, upgrade execution, monitoring
Development Team Application compatibility CQL query verification, functional testing
Infrastructure Team System environment JVM upgrade, network configuration
QA Team Quality assurance Full system testing, performance verification
Security Team Security review Security configuration review, vulnerability assessment

 

 

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:

 

 

Leave a Reply