← All posts
Jul 02, 2026 · Imad El Hassani

Build a Data Warehouse on Kubernetes, On-Premises

Your analytical data keeps growing. Postgres is straining. The cloud warehouse quote made your CFO wince, and your compliance team just asked where, exactly, the data would physically live.

You face a classic infrastructure dilemma: the workload demands a real MPP warehouse, but the usual paths — an appliance contract or a cloud provider — are both off the table.

There’s a third path, and it has quietly matured: run the warehouse yourself, on Kubernetes, on your own hardware. Let’s walk through why this became viable, what it takes, and how to deploy one.

Why this wasn’t viable before

Self-hosting an MPP database was never a software problem. Greenplum has been open source for years. The problem was everything around the software.

A shared-nothing MPP cluster is not a fleet of identical replicas. It’s a coordinator, a standby, and pairs of primary and mirror segments — with rules. A mirror must never sit in the same failure domain as its primary. Initialisation happens in a precise order. Recovery after a node failure is a multi-step choreography, not a restart.

On bare metal, all of that lived in runbooks and in the heads of a few senior engineers. Expansion was a project. Failover was an incident. The operational tax is what pushed everyone to appliances or the cloud — you weren’t paying for the engine, you were paying for someone else to operate it.

Then, in May 2024, the software problem came back — abruptly. Broadcom took Greenplum closed-source: the GitHub repositories were archived and made read-only, the community Slack was deleted, the mailing lists went silent, all without an announcement. Teams running open-source Greenplum in production woke up to a project with no future releases and no security updates unless they signed a Tanzu contract.

Two things changed the math back:

  • Apache Cloudberry — created by original Greenplum developers and now developed under the Apache Software Foundation’s incubator — gave the ecosystem an actively maintained, community-governed continuation of Greenplum. The engine question has a clean open-source answer again, and this time no single vendor can archive it.
  • Keldon Kubernetes operators made it possible to encode those runbooks as software. The recovery choreography, the placement rules, the initialisation order — all reconciled continuously by a controller instead of executed by a human at 3 a.m.

What is Keldon?

Keldon is an open-source Kubernetes operator for Apache Cloudberry. It extends the Kubernetes API with custom resources, so a warehouse cluster becomes something you declare rather than something you build.

Think of it this way: Cloudberry is the engine that plans and executes your queries across segments. Keldon is the crew chief — it doesn’t run your SQL, but it makes sure every segment is provisioned, placed, secured, and recovered so the engine can do its job.

You write a manifest describing the cluster you want. The operator makes it exist, and keeps it existing:

  • Provisioning: coordinator, standby, and mirrored segments from declarative YAML.
  • Placement: primaries and mirrors automatically spread across failure domains.
  • Security: TLS everywhere, issued and rotated through cert-manager from a CA you control.
  • Day-2: configuration changes, monitoring through your existing Prometheus stack, GitOps-friendly upgrades.

Getting started

1. Install cert-manager

The operator uses admission webhooks and TLS-secured cluster communication, so cert-manager is a prerequisite:

helm repo add jetstack https://charts.jetstack.io --force-update
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

In an air-gapped environment, point your issuer at your internal CA.

2. Install the Keldon operator

helm repo add keldon https://charts.keldon.io
helm install keldon-operator keldon/keldon-operator \
  --namespace keldon-system \
  --create-namespace

3. Register a database image

Keldon separates which Cloudberry to run from what the cluster looks like. First, declare the image as a DatabaseImage resource. Save this as database-image.yaml:

apiVersion: keldon.io/v1alpha1
kind: DatabaseImage
metadata:
  name: cloudberry-2.1.0
spec:
  version: "2.1.0"
  image: ghcr.io/keldonio/cloudberry:2.1.0

Apply it:

kubectl apply -f database-image.yaml

NAME               VERSION   IMAGE                                AGE
cloudberry-2.1.0   2.1.0     ghcr.io/keldonio/cloudberry:2.1.0   5s

4. Declare your warehouse

Now describe the cluster itself. Save the following as database-cluster.yaml:

apiVersion: keldon.io/v1alpha1
kind: DatabaseCluster
metadata:
  name: warehouse
spec:
  databaseImage: cloudberry-2.1.0
  mirroring: true
  standby:
    enabled: true
    storage: 10Gi
    storageClassName: local-path
  coordinator:
    storage: 10Gi
    storageClassName: local-path
  segments:
    count: 2
    storage: 10Gi
    storageClassName: local-path

Apply it:

kubectl apply -f database-cluster.yaml

The operator takes it from there: pods scheduled with mirrors kept apart from their primaries, the coordinator and standby configured, TLS provisioned. (The local-path storage class is fine for a demo; in production, use your CSI driver.) Connect with any Postgres client — the wire protocol, drivers, and your BI tools all just work.

When do you actually need this?

Start simple. Reach for a Kubernetes-based MPP warehouse when the signals stack up:

  • Scale: single-node Postgres is at its limits and the growth curve isn’t slowing.
  • Workload: your queries are join-heavy analytical SQL, not point lookups or real-time dashboards.
  • Constraints: data residency, regulation, or economics rule out the cloud warehouses.
  • Platform: you already run Kubernetes in production and want the warehouse managed the same way as everything else.

Two or three of these, and you’re the reader this post was written for.

FAQ

Does Kubernetes slow the database down? With local NVMe storage and proper resource allocation, the overhead is marginal. The performance conversation is about storage and network topology, not about pods vs. processes.

Can I migrate from Greenplum? Yes — and if you’re on open-source Greenplum, you should be planning to, since it no longer receives releases or security updates. Cloudberry was created by original Greenplum developers as its open-source continuation: the data model, distribution keys, and SQL transfer directly.

Isn’t cloud cheaper anyway? For spiky workloads, often yes. For a warehouse running 24/7 with steady load, on-premises economics usually win over a multi-year horizon — which is a big part of why “data repatriation” became a trend rather than a contrarian take.

Join us

Declare your warehouse. Let the operator do the operating.