# CockroachDB Helm chart

> Helm chart for deploying cockroachdb datastore

Source: https://zop.dev/integrations/cockroachdb
Updated: 2026-09-11 · Tags: datasource, helm, kubernetes

---

The CockroachDB Helm chart provides an easy way to deploy CockroachDB, a distributed SQL database built on a transactional and strongly-consistent key-value store. This chart allows you to manage CockroachDB instances on Kubernetes with customizable resource allocation, persistence, and scaling options.

---

## Prerequisites

- Kubernetes 1.19+
- Helm 3+

---

## Add Helm Repository

Before deploying the CockroachDB chart, add the Helm repository to your local setup:

```bash
helm repo add zopdev https://helm.zop.dev
helm repo update
```

For more details, refer to the [Helm Repository Documentation](https://helm.sh/docs/helm/helm_repo/).

---

## Install Helm Chart

To install the CockroachDB Helm chart, use the following command:

```bash
helm install [RELEASE_NAME] zopdev/cockroachdb
```

Replace `[RELEASE_NAME]` with your desired release name. For example:

```bash
helm install my-cockroachdb zopdev/cockroachdb
```

To customize configurations, provide a `values.yaml` file or override values via the command line.

See [Helm Install Documentation](https://helm.sh/docs/helm/helm_install/) for more information.

---

## Uninstall Helm Chart

To remove the CockroachDB deployment and all associated Kubernetes resources, use the following command:

```bash
helm uninstall [RELEASE_NAME]
```

For example:

```bash
helm uninstall my-cockroachdb
```

See [Helm Uninstall Documentation](https://helm.sh/docs/helm/helm_uninstall/) for additional details.

---

## Configuration

The CockroachDB Helm chart includes several configuration options to tailor the deployment to your needs. Below is a summary of the key configurations:

| **Input**                   | **Type** | **Description**                                                 | **Default**                     |
|-----------------------------|----------|-----------------------------------------------------------------|---------------------------------|
| `image`                     | `string` | Docker image and tag for the Cassandra container.               | `cockroachdb/cockroach:v25.1.2` |
| `resources.requests.memory` | `string` | Minimum memory resources required by the CockroachDB container. | `"512Mi"`                       |
| `resources.requests.cpu`    | `string` | Minimum CPU resources required by the CockroachDB container.    | `"100m"`                        |
| `resources.limits.memory`   | `string` | Maximum memory resources the CockroachDB container can use.     | `"512Mi"`                       |
| `resources.limits.cpu`      | `string` | Maximum CPU resources the CockroachDB container can use.        | `"100m"`                        |
| `diskSize`                  | `string` | Size of the persistent volume for storing CockroachDB data.     | `"10Gi"`                        |

You can override these values in a `values.yaml` file or via the command line during installation.

---

### Example `values.yaml` File

```yaml
resources:
  limits:
    cpu: 100m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 512Mi

diskSize : 10Gi

version: v25.1.2
```

To use this configuration, save it to a `values.yaml` file and apply it during installation:

```bash
helm install my-cockroachdb zopdev/cockroachdb -f values.yaml
```

---

## Features

- **Distributed SQL Database:** Deploy a scalable, distributed SQL database with strong consistency guarantees.
- **Persistent Storage:** Keep CockroachDB data intact across pod restarts with configurable persistent volumes.
- **Customizable Resource Allocation:** Tailor CPU and memory resources to match workload requirements.
- **Version Control:** Specify the CockroachDB version to deploy.
- **Multi-Database Support:** Configure multiple database services through the services configuration.
- **Easy Deployment:** Simplified Helm chart for rapid deployment of CockroachDB in Kubernetes environments.

---

## Pod Scheduling

`nodeSelector`, `tolerations` and `affinity` are passed straight through to the pod spec. All three are empty by default and render nothing, so leaving them unset changes nothing for an existing release.

They also apply to the cluster-init Job. A Job that could not tolerate the pool while the StatefulSet could would leave the cluster uninitialised, with the release still reporting `deployed`.

Together they place the workload on a dedicated node pool — the `nodeSelector` picks the pool, the toleration gets past its taint:

```yaml
nodeSelector:
  workload: stateful

tolerations:
  - key: workload
    operator: Equal
    value: stateful
    effect: NoSchedule
```

`affinity` takes a full [Affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) object. Note that setting it **replaces** the chart's default soft pod-anti-affinity (which spreads replicas across nodes) rather than merging with it — restate the anti-affinity alongside your own rules if you still want it.

---

## Contributing

We welcome contributions to improve this Helm chart. Please refer to the [CONTRIBUTING.md](https://github.com/zopdev/helm-charts/blob/main/CONTRIBUTING.md) file for contribution guidelines.

---

## Code of Conduct

To maintain a healthy and collaborative community, please adhere to our [Code of Conduct](https://github.com/zopdev/helm-charts/blob/main/CODE_OF_CONDUCT.md).

---

## License

This project is licensed under the [LICENSE](https://github.com/zopdev/helm-charts/blob/main/LICENSE). Please review it for terms of use.
