Google AlloyDB

AlloyDB rewrote the storage layer. Your monitoring should too.

pg_stat_replication tells you little on AlloyDB. DBExplore tracks the log processing service, the columnar engine, and read-pool balance, the signals that actually predict AlloyDB incidents.

Request early access Book a demo

What goes wrong

Columnar or row store, no idea

pg_stat_statements cannot tell you whether a query used the columnar engine or vectorized execution, so analytics slowdowns look random.

Reads pointed at the primary

Applications silently connect to the primary IP instead of the read pool. The primary carries the load and nobody notices until it saturates.

Cache eviction storms

Columnar cache eviction turns a sub-second analytics query into a hundred-second one with no change to the plan.

What DBExplore does about it

Columnar engine visibility

Cache behaviour and columnar versus row execution, with eviction-storm detection.

Storage-layer lag

The AlloyDB replacements for WAL replay metrics, tracked as first-class signals.

Read-pool balance

Per-node load across the read pool, hot-node detection, and primary-versus-pool traffic split.

AlloyDB-specific detection rules

Failover recovery time, connection ceilings, and Omni deployments covered.

See the full platform Security & Trust

AlloyDB for PostgreSQL: questions we get first

AlloyDB Omni?

Yes. Omni deployments are detected and get the same columnar and storage signals where the extension exposes them.

Which versions?

Every PostgreSQL major version AlloyDB currently offers.

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.