Cassandra (Helm)
What does zop.dev create for Cassandra (Helm)?
zop.dev deploys Apache Cassandra inside your cluster as the `zop/cassandra` Helm chart, added as a datastore from the deploy canvas, with a 10Gi disk by default. Clients reach it on the standard CQL port, 9042. The bill is your own nodes and disks, because no managed service sits behind it.
| Field | Value |
|---|---|
| Cloud | cross-provider |
Apache Cassandra is a distributed wide-column database for high-write workloads. zop.dev deploys it in-cluster from its own Helm chart catalog, on any cluster it manages.
The zop/cassandra chart on the deploy canvas
A Helm release of the zop/cassandra chart inside the cluster, added as a datastore from the deploy canvas catalog.
Disk size and CQL port
chart zop/cassandra; diskSize default 10Gi; CQL port 9042.A datastore on the canvas, not a managed database
Cassandra appears among the datastore charts in the deploy catalog. It runs as pods and volumes in your cluster, not as a cloud-managed service.
One replica is a development posture
Cassandra’s whole design assumes a ring of peers. Its consistency guarantees come from quorum, and quorum needs at least 3 replicas. Running fewer collapses that to a single point of failure: one pod eviction, one node drain, and the database is down with it. That shape is right for development environments where the data is disposable, and wrong for anything whose data is not. Raising the count is a capacity decision too: each replica is a JVM with real memory appetite, multiplied across your nodes.
Disks outlive pods
Each replica claims a persistent volume at the chart’s disk size (10Gi by default), and those PVCs have their own lifecycle. A restarted or rescheduled pod reattaches its volume, which is the durability story, but volumes bill as cloud disks for as long as they exist, and deleting the Helm release does not necessarily delete the claims. Growth only goes one way: volumes can usually be expanded but never shrunk, so the 10Gi default is a floor that ratchets upward. Teardown hygiene means checking for orphaned PVCs after the release is gone.
A cluster-level resident
Cassandra is an in-cluster chart rather than a managed database. Practically, that means it is added from the deploy canvas catalog like the other in-cluster datastores, and it runs on your nodes rather than appearing as a separate cloud resource. Teams get an in-cluster wide-column store for high-write workloads without a managed-service bill. The corresponding trade is that operations, upgrades, and capacity are theirs to own.