Self-hosted, Patroni, and Kubernetes operators
The depth only self-hosted allows, across every HA orchestrator you run
On your own kernels DBExplore goes further than any managed cloud permits: eBPF probes on TCP and the Postgres binary, direct DCS reads, and topology discovery for every operator you run.
What goes wrong
Every operator speaks its own language
Patroni REST, CloudNativePG CRDs, Zalando, Crunchy, StackGres, repmgr. Each has a leader, a timeline, and a way to lose quorum, and none share a dashboard.
Failovers you learn about later
Leader flapping, split timelines, and a stuck sync replica are the incidents that surface in a post-mortem, not an alert.
Kernel-level causes, application-level symptoms
TCP retransmits and Postgres error logs explain latency that no pg_stat view can.
What DBExplore does about it
The operational detail behind this: where the agent runs, and what it connects as.
HA orchestrator coverage
Patroni, pg_auto_failover, repmgr, Stolon, CloudNativePG, Crunchy, StackGres, Zalando and more, rendered on one topology panel with split-brain banners.
Deep Patroni signals
Timeline divergence, sync-state, cascade detection, DCS drift, and post-switchover write readiness, with anomaly rules for flapping, failover storms, stuck replicas, and lost quorum.
Kernel-level probes
Network and Postgres log events captured from the kernel on self-hosted hosts.
Topology discovery
Engine, HA, pooler, backup, replication, extensions, and monitoring stack discovered on first connection and re-checked on a schedule.
Self-hosted and Kubernetes: questions we get first
Do you need cluster-admin?
The agent reads operator resources with a namespaced read-only role. Kernel probes need a privileged sidecar or DaemonSet and degrade gracefully if the kernel refuses them.
Which Postgres versions?
All currently supported PostgreSQL major versions.
Which poolers?
PgBouncer, PgCat, Odyssey, pgagroal, Pgpool, and Supavisor.
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 Self-hosted and Kubernetes.
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.