DSE proprietary features
DataStax Enterprise is a distribution of Apache Cassandra with a support contract and a set of proprietary components added across successive releases. Those components run only on DSE, so the more a deployment relies on them, the more work a migration involves. The first step of any DSE migration is therefore to identify which of them are in use.
This page is a reference for the proprietary components, their open-source replacements, and the SSTable compatibility facts that determine the migration path. The replacement procedures themselves are covered in Component Migration.
Proprietary components and their replacements
Section titled “Proprietary components and their replacements”| Component | What it is | Why it is DSE-only | Open-source replacement |
|---|---|---|---|
| DSE core | A fork of Apache Cassandra 3.11 with proprietary modifications | Proprietary SSTable format (BTI in 6.0+) and EverywhereStrategy system keyspaces | open-source Apache Cassandra |
| DSE Search | A modified Apache Solr (Solr 6.0.1, 2016, long end-of-life) with proprietary enhancements | CQL-integrated indexing, real-time indexing, and multi-DC index spanning not available in open-source Solr | OpenSearch (or Elasticsearch)* |
| DSE Analytics | Bundled Apache Spark (Spark 2.0–2.4, all end-of-life) co-located on Cassandra nodes | Proprietary connector couples the Spark lifecycle to DSE nodes | Apache Spark + the Spark-Cassandra Connector |
| DSE Graph | Apache TinkerPop with a proprietary Cassandra storage backend | Storage layer not available outside DSE | JanusGraph, or denormalised Cassandra tables |
| Advanced Security | LDAP, Kerberos, row-level ACLs, transparent data encryption | Proprietary security layer tied to the DSE runtime | Native Cassandra authentication/authorization + external tools |
| NodeSync | Continuous background repair | DSE-only; no open-source equivalent ships with Cassandra | A workload-aware repair scheduler such as AxonOps Adaptive Repair (see Post-Migration Operations) |
| OpsCenter | Monitoring and management tool | Supports DSE only; does not work with open-source Cassandra | A Cassandra operations platform such as AxonOps |
* AxonOps recommends OpenSearch as the replacement for DSE Search, because it is Apache-2.0 licensed and fully open source. Elasticsearch is an alternative.
Many DSE deployments license components they never use in production. Before planning a replacement for Search, Analytics, or Graph, confirm whether the component is actually active (see Assessment).
SSTable compatibility: the critical decision point
Section titled “SSTable compatibility: the critical decision point”The single most important factor in choosing a migration approach is SSTable and protocol compatibility. Each DSE major version is a fork of a specific Apache Cassandra version.
| DSE version | Underlying Cassandra | SSTable compatibility | Migration approach |
|---|---|---|---|
| DSE 4.0–4.6 | Cassandra 2.0 | Compatible with OSS 2.0 | CDM/ZDM, or second datacenter |
| DSE 4.7–4.8 | Cassandra 2.1 | Compatible with OSS 2.1 | CDM/ZDM, or second datacenter |
| DSE 5.0 | Cassandra 3.0 | Compatible with OSS 3.0 | CDM/ZDM, or second datacenter |
| DSE 5.1 | Cassandra 3.11 | Compatible with OSS 3.11 | CDM/ZDM, or second datacenter |
| DSE 6.0+ | Cassandra 3.11 (forked) | Incompatible with OSS | CDM/ZDM (recommended); second datacenter is expert-only |
| DSE 6.8+ | Cassandra 3.11 (forked) | Incompatible with OSS | CDM/ZDM (recommended); second datacenter is expert-only |
While DSE 4.x and 5.x SSTables are compatible with their underlying Cassandra versions, an in-place binary swap would only target Cassandra 2.0–3.11, all of which are multiple major versions behind the current release and are not practical production targets today. For that reason, a data migration to a new open-source Apache Cassandra cluster is the recommended approach for all DSE versions.
DSE 6.0+ breaks ring-level compatibility
DSE 6.0+ is based on a fork of Cassandra 3.11 (end-of-life in 2024) and introduces two breaking changes that prevent even an in-place swap to Cassandra 3.11:
- The proprietary BTI SSTable format is incompatible with open-source Cassandra. Starting Apache Cassandra against DSE 6.0+ SSTables fails at startup.
- DSE system keyspaces use
EverywhereStrategy, a replication strategy class that does not exist in open-source Cassandra, so an open-source node fails at startup withClassNotFoundException. This class is present in DSE 5.x as well, where it is remediable before a node joins the ring (see remediating proprietary classes). On DSE 6.0+ it sits alongside the BTI format above, which has no equivalent remediation.
Mixed DSE 6.x / open-source Cassandra rings are not supported by either DataStax or the Apache Cassandra project. A second-datacenter migration on DSE 6.0+ is therefore expert-only and must be proven by a PoC; for DSE 6.0+, a data migration (CDM/ZDM) to a separate target cluster is the safest and recommended approach.
Determine the DSE version
Section titled “Determine the DSE version”Run the following on a DSE node:
# Reports the DSE distribution version (e.g. 5.1.x, 6.8.x)dse -vnodetool version returns the underlying Apache Cassandra version, not the DSE distribution version. The dse -v output is what governs SSTable compatibility and therefore the migration path.
Replacing OpsCenter: the day-2 operations gap
Section titled “Replacing OpsCenter: the day-2 operations gap”OpsCenter is worth singling out because it is the first component to stop working. OpsCenter supports DSE only: it stops working as soon as a DSE node is replaced by an open-source Cassandra node. Unlike Search or Analytics, this is not an optional component that might not be in use: most DSE deployments rely on OpsCenter for dashboards, repair, backup, and alerting, and a replacement must be in place before cutover, not after.
Open-source Cassandra does not ship an equivalent all-in-one management tool, so this gap must be filled deliberately. The following table maps common OpsCenter capabilities to equivalents in the AxonOps operations platform.
| OpsCenter capability | Equivalent |
|---|---|
| Performance dashboards | Dashboards |
| Alert rules | Curated alerts + custom rules |
| Repair service | Adaptive (workload-aware) repair |
| Backup service | Backup with point-in-time restore (PITR) |
| Node administration | Rolling restarts, nodetool integration |
| Log viewing | Integrated log management |
| Capacity planning | Metrics and trending dashboards |
| Service monitoring | Service health checks |
| Multi-DC visibility | Multi-cluster support |
AxonOps monitors both DSE and open-source Cassandra simultaneously, so a single tool covers the source cluster, the target cluster, and the mixed state during migration, which OpsCenter cannot do. This is also why monitoring is installed early in the migration (see Monitoring & Baseline). For support, tooling, or help replacing OpsCenter, see the AxonOps Cassandra offering.
Do-it-yourself tooling versus AxonOps
Section titled “Do-it-yourself tooling versus AxonOps”Assembling a Cassandra operations stack from separate open-source tools is a common approach. The licence cost and the total cost of ownership differ: each tool requires ongoing deployment, integration, and maintenance work.
A do-it-yourself Cassandra operations stack is typically several separate projects:
- Reaper for repair scheduling;
- Medusa for backups;
- a JMX exporter or MCAC feeding Prometheus and Grafana for metrics and dashboards;
- a separate log shipping and search stack (for example Filebeat or Promtail into Elasticsearch/OpenSearch or Loki);
- and alerting wired across all of the above.
Each is a project to deploy, secure, integrate, upgrade, and keep current, often with several agents running on every node. AxonOps replaces that whole set with one agent and one platform covering metrics, logs, dashboards, repair, backup and restore, alerting, and rolling restarts.
On metrics collection specifically, the difference is large. Measured at a common 5-second resolution, the methods compare as follows (the cost of collecting metrics):
| Aspect | axon-agent | JMX Exporter | MCAC |
|---|---|---|---|
| Tables monitored before CPU saturates | 1,000+ (15-min load ~0.33) | barely 100 (struggles past 200) | ~300 idle |
| Monitoring data transferred, same workload | baseline | ~7x more (AxonOps uses ~14% of JMX bandwidth) | ~260x more (AxonOps uses ~0.38% of MCAC bandwidth) |
| Effect on the database under load | 2x the write throughput and 40% faster reads versus a JMX-monitored cluster | lowered write throughput | very high data volume |
The agent connects outbound only (no inbound firewall rules).
Repair. Reaper is an open-source repair scheduler, but it runs repair on a fixed
schedule that cannot react to what the cluster is doing. AxonOps Adaptive Repair
treats repair as a load-regulated feedback loop: it watches pending tasks,
coordinator and replica latency, and I/O wait at 5-second resolution and adjusts the
pause between segments and the parallelism in real time, completing inside the
gc_grace_seconds window without treating the cluster as if it were always idle. The
mechanism is described in
Adaptive regulation of Cassandra repair,
and it runs across hundreds of production clusters.
Backup. Medusa is an open-source backup tool, but it does not provide point-in-time restore. AxonOps backup adds commitlog archiving, which enables restore to any point in time rather than only to the last snapshot. It reduces the backup surface to a single managed dependency rather than a set of independently maintained projects.
Beyond OpsCenter: AI-powered operations
Section titled “Beyond OpsCenter: AI-powered operations”AxonOps includes capabilities OpsCenter does not: an AI layer, trained on Apache Cassandra and grounded in the cluster's topology and configuration, that targets real day-2 operational problems:
- AI Chat. Ask questions about specific clusters in plain English (topology, configuration, performance, best practice), with answers grounded in the cluster's environment rather than generic documentation.
- Alerts root-cause analysis. When an alert fires, AxonOps correlates metrics, events, and configuration and surfaces the most likely root cause with remediation steps. This reduces a multi-step investigation that would otherwise involve cross-referencing dashboards and escalating to a senior engineer, and captures an audit trail for the post-mortem.
- Recommendations. A continuous health assessment that surfaces issues before they become incidents (compaction backlog, repair drift, oversized heaps, right-sizing opportunities) in plain language.
- Custom AI model. Run the default AxonOps AI, or point it at an LLM approved by the security team (Azure OpenAI, AWS Bedrock, Anthropic, OpenAI, or an internal model). The Cassandra domain knowledge stays in the platform either way.
The AxonOps AI for Cassandra and Kafka operations webinar demonstrates these capabilities. See AxonOps AI for the full feature set, and the AxonOps Cassandra offering for how the AI layer fits alongside monitoring, repair, and backup.
Frequently asked questions
Section titled “Frequently asked questions”Is DSE based on Apache Cassandra?
Section titled “Is DSE based on Apache Cassandra?”Yes. Each DSE major version is a fork of a specific Apache Cassandra version with proprietary additions; DSE 6.x is based on Cassandra 3.11.
What replaces OpsCenter for open-source Cassandra?
Section titled “What replaces OpsCenter for open-source Cassandra?”OpsCenter only supports DSE. A Cassandra operations platform such as AxonOps replaces its dashboards, alerting, repair, and backup, and works with open-source Cassandra.
Is AxonOps better than Reaper, MCAC, or a DIY Prometheus stack?
Section titled “Is AxonOps better than Reaper, MCAC, or a DIY Prometheus stack?”AxonOps replaces that whole tool chain with one agent and one platform. Its metrics agent monitors 1,000+ tables at low overhead, and Adaptive Repair regulates repair by live cluster load rather than running on a fixed schedule.
Do DSE Search and Analytics have open-source replacements?
Section titled “Do DSE Search and Analytics have open-source replacements?”Yes. DSE Search maps to OpenSearch, DSE Analytics to Apache Spark with the Spark-Cassandra Connector, and DSE Graph to JanusGraph or denormalised tables.