Veritas vs Patroni — and vs pg_auto_failover
Patroni and pg_auto_failover are Postgres-only consensus monitors — they watch a single engine and rely on human-operated promotion. Veritas is engine-spanning, models the observe → diagnose → act → verify loop natively, and runs the same closed loop on Postgres, CockroachDB, Cassandra, YugabyteDB without per-engine wrappers.
Side-by-side at a glance
Five dimensions the FAQ accord lands on, expanded into a full comparison.
| Capability | Patroni | Veritas |
|---|---|---|
| Detection (sub-30-second anomaly) | Threshold-only; misses in-band drift | Yes Continuous signal + diagnose in the same loop |
| Recovery (autonomous, unsupervised) | Promotes the replica, hands off to a human | Yes Generates, risk-scores, and executes the fix plan |
| Audit trail (SOC 2 Type II) | Limited — Prometheus + logs, no tamper-evident ledger | Yes Tamper-evident log with root-cause annotation per action |
| Multi-engine support | Postgres only — pg_auto_failover and Patroni are engine-internal | Yes Postgres, CockroachDB, Cassandra, YugabyteDB from the same agent |
| Operational overhead | etcd or consul quorum to operate alongside Postgres itself | Yes None on the data plane — agent is read-mostly |
Where Patroni stays silent
Three failure modes the threshold and the consensus loop are built to miss — and what the closed loop does instead.
Patroni watches a configurable lag threshold and calls the cluster healthy while lag compounds inside it.
A replica falls behind by a few seconds every poll cycle. Nothing crosses the threshold Patroni is configured to alert on, so the cluster reads as healthy. Six hours later the lag has compounded into the minute range, the WAL receiver is saturated, and writes block. Patroni has been quiet the whole time because each individual reading was below the trip-wire.
Veritas observes the *trend* — every cycle's delta, not just the instantaneous value — and flags the compounding drift inside the threshold band. The diagnose step correlates the lag slope with WAL pressure on the primary, the act step pauses non-critical writes long enough to let the replica catch up, and the verify step replays a probe write to confirm read-your-writes holds before the incident is closed.
Patroni's quorum is engine-internal and can't arbitrate between two nodes that both believe they hold the lease.
A partition splits the cluster and a replica promotes itself while the primary is still serving writes on the other side of the fence. Both sides now believe they own the leader lease; reads against either return their own last-known-good state. Read-what-you-wrote is broken, and until the partition heals there is no single source of truth.
Veritas reads quorum state, replica liveness, and lease ownership *across* the affected nodes before any action is taken. If the cluster cannot prove exactly one eligible leader, every remediation plan is refused; the agent waits for the partition to resolve and then performs a single, audited promote against the node the verify step can prove is canonical.
Patroni promotes the replica with the freshest WAL and stops. Nothing checks that the read view is actually serving the latest writes.
A failover completes cleanly — Patroni promoted the most-up-to-date replica, the old primary is fenced, replication is re-established. The new leader looks healthy and the alert clears. But a side effect of the rapid promotion is that the cached read view is serving rows from before the failover was even attempted. Application reads start returning stale data and the bug only surfaces when a customer notices.
Veritas treats the recovery as incomplete until the verify step proves a real, end-to-end read against the new leader returns the data the cluster most recently committed. If the verify probe fails, the diagnose step rolls the promotion back and retries against a different replica — the incident stays open until a real probe, not a heartbeat, confirms the read view is current.
Same engine list, a closed loop on top
Veritas does not replace your consensus monitor. It runs on topof it — same engines, same operators, same backups, plus a sub-30-second recovery loop that closes on its own. One agent, one audit trail, one verify step per incident.
Or write directly to veritas-2-2@polsia.app.