CloudNativePG
No external store, no Patroni, and no session history either
CloudNativePG drops the external failover store on purpose: the Kubernetes API server holds the cluster status and the instance manager acts on it. That makes failover legible and leaves every query-level question to somebody else.
What goes wrong
There is no consensus store to poll
No etcd, no Consul, nothing to curl. Status lives in the Cluster resource and the instance manager reconciles against it, so an alerting stack built around a distributed configuration store has nothing to watch.
The exporter answers only what it was asked
The default monitoring ConfigMap covers the obvious. Past it, every metric is a custom query you write, version and keep working across operator upgrades, in an exporter that deliberately drops the upstream caching field.
Readers pointed at the wrong service
The read-write, read-only and read-any services are three lines in a values file that look interchangeable. An application left on the wrong one sends every read to the primary and nothing complains.
What DBExplore does about it
The operational detail behind this: how the agent is deployed inside a cluster, and what it connects as.
The session evidence a time series cannot hold
Wait events, blocking trees and active session history retained long enough that a failover from last month still has the queries that were running attached to it.
Plan fingerprints across every instance
Structural plan fingerprints on primary and standbys alike. A regression needs a plan change and a measured slowdown against the best prior plan before it becomes an alert.
Topology and flavour discovery
Primary and standbys, synchronous state and replication lag, pooler, backup tooling and extensions, read from the Postgres connection on first contact and re-checked on a schedule.
It runs where your cluster runs
Self-hosted deployment, air-gapped included, with a fail-closed policy gate, approval by default, a signed ledger, and an MCP interface so your own agents ask the same questions under the same rules.
CloudNativePG: questions we get first
Do you install a CRD, a webhook or an operator plugin?
None of those. There is no CloudNativePG controller from us and DBExplore does not manage your cluster. It connects as a read-only Postgres role and reads.
Does this replace the Prometheus exporter?
No, and running both is the right answer. The exporter is where threshold alerting belongs. DBExplore holds the session-level evidence and the causal narrative that a metric series cannot carry.
How does the agent connect?
A container, Kubernetes deployment or sidecar, or native package next to your databases, using a read-only monitoring role over a small connection pool with short statement timeouts. No superuser.
Can DBExplore change anything without approval?
Not by default. Every tenant starts at approve. Disruptive actions always need two approvers, and every mutating action passes a fail-closed policy gate first.
Run DBExplore on your CloudNativePG.
We onboard teams in small batches. Tell us about your fleet and we will reach out when a seat opens. One email, no drip campaign.