Crunchy Bridge and Crunchy Postgres for Kubernetes
A real superuser, and a console that forgets
Crunchy hands you more of Postgres than any hyperscaler does. What it does not hand you is a record: Bridge documents that its metrics reset on failover and upgrade, and the exporter sidecar in Crunchy Postgres for Kubernetes is a time series, not a session history.
What goes wrong
The chart empties at the failover
Bridge resets metrics on failover, upgrade and version change, and can show duplicates while high availability is on. The window you most want to read is the one that was cleared.
Insights are a snapshot, not a trend
Outlier queries, cache and index hit rates, unused indexes and bloat are all in the console, computed for right now. Nothing there tells you the outlier is new this week.
Two products, two operating models
Bridge is a managed cluster where an administrator holds a genuine superuser. Crunchy Postgres for Kubernetes is Patroni electing a leader through a lease on a Kubernetes object. One health check does not describe both.
What DBExplore does about it
History that survives the switchover
Active session history, wait events, blocking trees and plan fingerprints are retained on our side of the connection, so the event that cleared the vendor chart still has a before and an after.
Discovery instead of an inventory document
Engine and version, replication shape and lag, the pooler in front, backup tooling and the extensions present, read on first connection and re-checked on a schedule across both shapes.
Index and plan advice from the catalog
Index candidates ranked from catalog statistics and query history, and plan-regression detection that needs a structural plan change and a real slowdown before it fires. Neither needs host access.
A genuine superuser makes the gate matter more
Nothing DBExplore proposes skips the fail-closed policy gate because the privilege happens to exist. Mutating actions need a human by default and land signed in the ledger either way.
Crunchy Bridge and Crunchy PGO: questions we get first
Is there a Crunchy Bridge connector?
No, and we will not imply one. DBExplore connects as a read-only Postgres role over the standard protocol, the way it connects anywhere, and works out what the cluster is from the catalog.
How is the pooler counted?
Bridge runs PgBouncer on its own port in transaction pooling mode and denies superuser and replication roles through it. Connect the monitoring role directly and pooled and direct connections stay separate numbers.
What leaves the database?
Metrics, catalog metadata, execution plans, and query text with literals scrubbed on the agent before it is sent. Parameter capture is off by default. Row data never leaves.
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 Crunchy Bridge and Crunchy PGO.
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.