Veritas vs Zalando Postgres Operator— Kubernetes-only reconciliation vs engine-spanning autonomous recovery
The Zalando Postgres Operator is a Kubernetes CRD controller scoped to a single engine — it surfaces state, hands the fix back to the operator, and calls that autonomy. Veritas runs the observe → diagnose → act → verify loop end-to-end, and runs the same closed loop on Postgres, CockroachDB, Cassandra, YugabyteDBacross Kubernetes, bare metal, and VM — not just inside one orchestrator.
Side-by-side at a glance
Five dimensions where Kubernetes-native reconciliation and engine-spanning autonomous recovery take different paths.
| Capability | Zalando Postgres Operator | Veritas |
|---|---|---|
| Detection latency | Reconciliation-loop only — CRD status polls add seconds to tens of seconds on top of the underlying fault | Yes Sub-30-second closed loop; observe → diagnose in the same tick |
| Failover automation | Surfaces state to the cluster, hands back to the operator for action | Yes Generates, risk-scores, and executes the fix plan autonomously |
| Multi-engine support | Postgres-only, Kubernetes-only — the operator is a CRD controller scoped to a single engine | Yes Postgres, CockroachDB, Cassandra, YugabyteDB on bare metal, VM, and Kubernetes from the same agent |
| Audit retention | Kubernetes event log only — no tamper-evident chain linking decisions to actions | Yes Tamper-evident hash chain — 90-day Pro / 12+ month Enterprise retention with root-cause annotation per remediation |
| Operational overhead | CRD controller that participates in the data plane alongside the replicas | Yes Read-mostly on the data plane — no consensus vote, no replica-schedule ownership |
Where the CRD reconciliation loop stays silent
Three failure modes the Kubernetes-native control plane is built to miss — and what the closed loop does instead.
The Zalando operator reports Ready=True because the Kubernetes liveness probe passes — even when the underlying cluster is silent on a real fault.
A replica stalls on WAL apply. The Kubernetes liveness probe still answers on its assigned port, so the CRD's status condition reads Ready=True, and the operator's reconciliation loop marks the cluster healthy. Thirty seconds in, the replica is still behind; a minute in, the apply gap has compounded and writes are starting to block. The K8s abstraction layer never noticed because each individual probe answered correctly.
Veritas detects the drift from the engine itself, not from the Kubernetes abstraction. The observe step reads the WAL apply position, the lag slope, and the replica's last-committed LSN directly from Postgres — independent of whether K8s believes the pod is healthy. When the trend crosses the in-band threshold, the diagnose step correlates it with primary WAL pressure and the act step pauses non-critical writes long enough for the replica to catch up.
The operator's leader-election loop hands the lease to whatever replica the scheduler picks — not the one the engine can verify.
A node drain moves the primary across an availability-zone boundary. The operator elects a leader from the surviving replicas and updates the CRD. The new leader looks healthy, but the replica it picked has not yet applied the most recent WAL segment — promotions decisions in the operator are made off scheduling state, not off the engine's consistency view. Reads start returning rows from before the drain was even attempted.
Veritas waits for the verify step to prove a real probe write returns read-your-writes before closing the incident. The act stage generates a fix plan that ranks surviving replicas by their last-applied LSN, not by Kubernetes scheduling fitness; promotion is only attempted against the replica the engine can prove is canonical. If the verify probe fails against the preferred choice, the diagnose step rolls the plan back and retries the next-best candidate — the incident stays open until a real probe, not a status condition, confirms the leader is current.
The Kubernetes event log is mutable and doesn't link operator decisions to engine-level action.
Six weeks after an incident, an auditor asks why the automated decision chose the replica it did, what evidence the decision saw at the moment it ran, and what would have happened if a different replica had been selected. The K8s event log shows the promotion occurred; it does not show the consensus-protocol view the action was taken against, the alternatives that were considered, or the verify probe that approved it. The event log is also mutable and not chained across events, so any retroactive edit is undetectable.
Veritas records every step of the closed loop — observe, diagnose, act, verify — into a tamper-evident hash chain. Each entry links the prior entry's digest, the engine-level signal that triggered the decision, the remediation plan with its scored alternatives, and the verify probe that closed the incident. The chain is append-only, signed at rest, and retained for 90 days on Pro / 12+ months on Enterprise, so an audit review can replay the exact decision path without relying on a mutable platform log.
Same engine list, a closed loop on top
Veritas does not replace your Kubernetes operator. It runs on topof it — same clusters, same CRDs, same backups, plus a sub-30-second recovery loop that closes on its own and a tamper-evident ledger that ties each action to the engine signal that triggered it. One agent, one audit trail, one verify step per incident.
Or write directly to veritas-2-2@polsia.app.