24/7 Apache Cassandra Support with a 15-Minute Emergency SLA

Cassandra support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, data model review, compaction and repair strategy, JVM and GC tuning, CVE and patch advisory, quarterly health checks, and upgrade or multi-DC expansion support. Every ticket goes to a named senior engineer assigned to your account. There is no first-line triage layer and no per-incident charge.

That is the tombstone problem, and it is the single most common Cassandra incident we are called for. Cassandra does not remove data on delete; it writes a tombstone marker that has to be scanned on every subsequent read of that partition until it ages past gc_grace_seconds and a compaction removes it. Frequent deletes or short TTLs on a table therefore make reads progressively more expensive, and a query that scans past tombstone_failure_threshold is aborted outright. We fix it in layers: immediate relief through targeted compaction, then a repair schedule that actually completes, then the data model change that stops generating the tombstones — usually a switch to time-bucketed partitions with TWCS instead of in-place deletes.

P1 emergencies — multiple nodes down, reads or writes failing cluster-wide, a ring that won't converge — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times covering nights, weekends, and holidays.

Yes. We support Apache Cassandra 3.11 through 5.0, DataStax Enterprise, Azure Managed Instance for Apache Cassandra, and Amazon Keyspaces. The managed and commercial variants remove some operational surface — Keyspaces in particular hides compaction and repair entirely — but they do not remove partition sizing, consistency level design, or the cost model consequences of a wide partition. We are also frequently asked to compare them honestly for a specific workload, including where the managed option genuinely wins.

Every table needs a full repair to complete within gc_grace_seconds, which defaults to ten days. If it does not, tombstones can be purged before every replica has seen them and deleted data comes back. Repairs fail or overrun for a handful of recurring reasons: very wide partitions that blow past stream timeouts, insufficient compaction throughput, running full repairs where incremental or subrange would fit the window, and overlapping repair sessions competing for the same ranges. We usually move customers onto a subrange schedule driven by a scheduler such as Reaper, sized so the whole ring completes with margin rather than finishing on the last day.

Yes, and this is a rolling upgrade that has to be sequenced carefully rather than a package update. SSTable format changes mean nodes on different major versions cannot stream to each other, so no bootstrap, decommission, or repair can run until the whole ring is upgraded — which makes the window between the first and last node the risky part. We rehearse on a cloned cluster, verify driver compatibility, upgrade SSTables node by node, and keep a tested rollback point. We also check for deprecated configuration and CQL behaviour changes that surface as application errors rather than server errors.

Apache Cassandra is an open source, distributed NoSQL database from the Apache Software Foundation, designed for fault tolerance and linear scalability with no single point of failure. The Cassandra community maintains current releases and answers questions on the mailing lists and Slack, with no SLA. Commercial support comes from DataStax for DataStax Enterprise and Astra, from managed Apache Cassandra providers for their own services, and from independent providers such as AceMQ for the clusters you run yourself. We cover open source Cassandra on any version, on-premises and in the cloud, with dedicated Cassandra experts for troubleshooting, data model reviews, read and write performance tuning, repair and compaction, and upgrades off unmaintained 3.x releases to 4.x and Cassandra 5.0.

Usually. Most Cassandra performance problems are data model problems discovered at scale: a partition key that lets one partition grow to gigabytes, tombstones from queue-like deletes, secondary indexes on high-cardinality columns, or a compaction strategy chosen for a workload the cluster no longer has. Others are configuration: heap and garbage collection settings that cause pauses, repair schedules that collide with peak load, or a consistency level that makes every read wait on the slowest replica. We diagnose from the metrics, the table histograms and the query patterns, fix what can be fixed online, and tell you plainly when the answer really is more nodes.

Yes. DORA, the EU Digital Operational Resilience Act, has applied since 17 January 2025 and requires financial entities to hold written contracts with their ICT suppliers, with service levels and incident assistance spelled out. AceMQ supports Cassandra under a contract that states response times by severity (15 minutes for P1, 1 hour for P2, 4 hours for P3, next business day for P4), 24/7 cover, a named senior engineer and a written root cause analysis after every P1. DORA does not certify suppliers, so the compliance judgement stays with you or your integrator.

Apache Cassandra is open source and runs wherever you put it: your data centre, any cloud, or Kubernetes. You choose the data model, replication factor and consistency level per query, and you run repair and compaction yourself. Amazon DynamoDB is a proprietary AWS service with no servers to run and a different pricing and lock-in profile. The two share the idea of partitioned, replicated key-based storage. Amazon Keyspaces sits between them, offering Cassandra-compatible access on AWS infrastructure. The choice usually turns on where the data must live and whether you want to operate a ring.

Yes to both. Managed Cassandra means AceMQ operates the ring: on your own cloud account, data centre or Kubernetes clusters, or hosted on AceMQ infrastructure, with repair, upgrades, node replacement and on-call included. Apache Cassandra consulting covers data model review, partition key design, compaction strategy and cluster assessments before or after go-live. Most teams start with support or an assessment and move to managed operations only if they want to stop running the ring.

Yes. AceMQ works on Apache Cassandra in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your Apache Cassandra environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Apache Cassandra is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.