YugabyteDB
YSQL on top, RocksDB underneath, monitored as such
pg_stat_bgwriter is meaningless here and a missing VACUUM is not a problem. DBExplore reads the tserver and master endpoints and sums per-node query statistics into a fleet view.
What goes wrong
Per-node statistics
Query statistics are per node on YugabyteDB. Without summing across nodes you are looking at a slice.
False vacuum alarms
Postgres tools flag missing autovacuum and inaccurate dead-tuple counts on an LSM storage engine that compacts instead.
Tablet and leader skew
One tserver holding too many leaders is the slow node, and nothing Postgres-shaped shows it.
What DBExplore does about it
Tablet and tserver health
Tablet distribution, leader skew, tserver availability, and master election churn.
Replication
xCluster and read-replica lag tracked per stream.
Storage engine signals
Compaction backlog and WAL growth, with clock skew and version mismatch alerts.
YugabyteDB-specific detection rules
With Postgres-only rules gated off so they never fire falsely.
YugabyteDB: questions we get first
YugabyteDB Anywhere and Aeon?
Yes. Deployment variant is detected from the connection and the collectors adapt.
Which versions?
YSQL-compatible releases; per-node query statistics require the YSQL statistics view.
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 YugabyteDB.
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.