Citus
The coordinator is not the cluster
Coordinator-only pg_stat_statements hides where the work happens. DBExplore reads citus_stat_activity and the wait-for graph so distributed problems are visible before they deadlock.
What goes wrong
Worker execution is invisible
Query statistics on the coordinator say a query took 40 ms. The worker that actually ran it took four seconds.
Distributed deadlocks
Citus needs its own detector. A wait cycle across two workers never shows in pg_locks on either.
Shard skew and stalled rebalances
Placement drifts, one worker fills up, and a rebalance stalls on wal_sender_timeout with nobody watching.
What DBExplore does about it
Worker and coordinator health
Per-worker reachability and coordinator standby lag.
Distributed lock wait edges
The wait-for graph across workers, surfaced as an event before it becomes a deadlock.
Shard inventory
Shards per worker, reference tables, total shard size, and skew detection.
Citus-specific detection rules
Covering worker availability, coordinator connections, and rebalance progress.
Citus: questions we get first
Azure Cosmos DB for PostgreSQL?
Yes. It is Citus under the hood and is monitored with the same signals plus Azure Monitor metrics.
Which Citus versions?
Current Citus releases on the host PostgreSQL version.
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 Citus.
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.