Apache Cassandra Support Options: Community, Vendor or Independent

Apache Cassandra has no vendor. Cassandra support comes from the Apache Cassandra community for maintained versions, from DataStax and the managed Apache Cassandra providers for their own products and services, and from independent providers for the self-managed Cassandra clusters that carry most production workloads.

What the Cassandra project maintains

Apache Cassandra is an open source, distributed NoSQL database designed for high availability with no single point of failure, replicating data across nodes and across multiple datacenters. The Cassandra project ties maintenance to releases, not calendar dates. Its download page currently lists Cassandra 5.0 as maintained until the 8.0 release, 4.1 until the 7.0 release, and 4.0 until the 6.0 release. Older versions are unmaintained and archived, and the project notes that CVE fixes may be applied to unmaintained versions on a case-by-case basis, which is not something to plan around.

Cassandra 3.x, including the 3.0 and 3.11 lines that a large share of on-premises estates still run, is therefore unmaintained. As with every Apache project, maintenance means releases. The Cassandra community answers questions on Slack and the mailing lists, with no SLA.

Vendors and managed services

DataStax, now part of IBM, sells DataStax Enterprise and the Astra cloud service, and supports those products. Instaclustr and others offer fully managed Apache Cassandra. Amazon Keyspaces and Azure Managed Instance provide Cassandra-compatible or managed options on AWS and Azure. Each supports its own service. None of them supports the open source cluster you deployed yourself on virtual machines or Kubernetes, and a managed service does not fix a data model.

The Cassandra incidents that actually page people

• Tombstones and read timeouts. Deletes and TTL expiry write tombstones, and a query that scans thousands of them to return a few rows fails with a read timeout. Queue-like usage and wide partitions with heavy deletes are the usual cause. The fix is in the data model and compaction strategy, not the timeout setting.
• Repairs that never complete. Anti-entropy repair is how replicas converge, and it must finish within gc_grace_seconds or deleted data can reappear. On large clusters repairs stall, overstream or collide with compaction, and many teams quietly stop running them.
• Compaction falling behind. Pending compactions climb, SSTable counts grow, read latency rises and disks fill. The strategy that suited the workload at launch may be wrong now, and changing it is itself a heavy operation.
• Large partitions. A partition key chosen for convenience lets one partition grow to gigabytes. Reads of that partition cause garbage collection pauses and heap pressure on every replica that owns it.
• Garbage collection pauses. Long JVM pauses make a node appear down to its peers, hints pile up, and coordinators time out. Heap sizing, the collector and off-heap settings need to match the workload and the Java version.
• Node replacement and scaling. Bootstrapping, decommissioning and replacing a dead node all stream large amounts of data. Done in the wrong order, or with inconsistent schema across nodes, they turn a hardware failure into an outage.

Upgrading off Cassandra 3.x

The upgrade is a rolling restart, one node at a time, with no downtime when it is done correctly. The rules are firm. Upgrade from a recent patch release of your current line, run upgradesstables after the binaries change, never run repair or make schema changes while the cluster is on mixed versions, and do not skip major versions beyond what the project documents as supported: 3.x clusters go to 4.0 or 4.1 before 5.0. Drivers need checking because 4.0 changed protocol defaults and removed Thrift, which still matters for very old applications. Cassandra 5.0 brings storage-attached indexes, the unified compaction strategy and support for newer Java versions, all worth having, none of which should be enabled on the day of the upgrade.

Open source or a commercial distribution?

The choice shapes your support options more than any other decision. Apache Cassandra is free, moves at the pace of the project and leaves support to you. DataStax Enterprise adds proprietary features, tooling and a vendor contract, and ties you to that vendor's versions and pricing. A managed service removes node operations and keeps the data model, query design and client behaviour as your responsibility. Many organisations run more than one of these across business units. Whatever the mix, ask any provider the same things: which versions they cover, whether an emergency response is an engineer or an acknowledgement, whether they will carry out the upgrade with you, and whether they will tell you when Cassandra is the wrong database for a workload.

Where independent Cassandra support fits

• Self-managed open source clusters, on-premises or in the cloud, with nobody to call.
• Unmaintained 3.x versions, while the upgrade is planned and rehearsed.
• Troubleshooting and performance tuning: latency, throughput, compaction, repair and JVM configuration for the real workload.
• Data model and schema reviews, because most Cassandra problems are CQL table design problems discovered at scale.
• Teams without Cassandra experts. A single administrator who understands the cluster is a single point of failure that the database itself was designed to avoid.

AceMQ provides 24/7 Cassandra support for Apache Cassandra on any version, with a 15-minute emergency SLA and named senior engineers. Examples: a tombstone and read timeout remediation and repair and compaction support. For how Cassandra's support window compares with other technologies, see support windows compared.