Topologies
Every shape Postgres comes in, discovered rather than declared
A fleet is not a list of connection strings. It is orchestrators, poolers, replication paths, backup tools and extensions, in combinations nobody wrote down. DBExplore works out what each cluster actually is, then routes every probe off that.
How it works
Seven dimensions, on first connection and then on a schedule
When a cluster registers, DBExplore probes it across seven dimensions and writes a topology descriptor. Every collector and every detection rule routes off that descriptor. If the descriptor says the orchestrator is Patroni, the Patroni probes fire. If it says the pooler is PgBouncer, the pooler probes fire.
Get that wrong and you get silent dead spots, which is why each dimension is probed rather than asked, strongest signal first, and why each answer carries a confidence score and a rationale written for whoever reads it at three in the morning.
- 01 Engine
- 02 High availability
- 03 Connection pooling
- 04 Backup and recovery
- 05 Replication
- 06 Extensions
- 07 Existing monitoring
Dimension 01
Engine
Which Postgres this actually is, not what the connection string claims.
How it is detected. Version strings, catalog fingerprints and cloud metadata, because a managed Aurora cluster and a self-hosted primary answer the same protocol and behave nothing alike.
What you get. Detection drives everything downstream. A rule written for Aurora never fires on CockroachDB, and storage internals that have no meaning on a distributed engine are never reported there.
Recognised
- PostgreSQL
- Amazon Aurora
- Aurora Serverless v2
- Aurora Global
- Amazon RDS
- RDS Multi-AZ
- Google Cloud SQL
- AlloyDB
- AlloyDB Omni
- Azure Database for PostgreSQL
- Neon
- Supabase
- TimescaleDB
- Timescale Cloud
- Citus
- CockroachDB
- YugabyteDB
- Crunchy Bridge
- EDB Postgres Advanced Server
- Aiven
- Heroku Postgres
- DigitalOcean
- Render
- Fly Postgres
- pgEdge
- OCI Postgres
Dimension 02
High availability
Who decides which node is the leader, and what happens when that decision goes wrong.
How it is detected. Orchestrator APIs where they exist, the distributed configuration store directly where they do not, and process inventory as the fallback.
What you get. Every orchestrator lands on one topology panel with its own consensus tier, plus banners for no leader, split leader and split timeline. Leader flapping, failover storms, a stuck synchronous replica and a lost quorum each have their own signature and runbook.
Recognised
- Patroni
- CloudNativePG
- Zalando operator
- Crunchy PGO
- StackGres
- repmgr
- pg_auto_failover
- Stolon
- PAF
- pglookout
- EDB Failover Manager
- Managed failover
- None
Dimension 03
Connection pooling
Postgres can be perfectly healthy while the pooler in front of it is on fire.
How it is detected. Protocol probes, the pooler admin interface where one exists, and session inspection.
What you get. Pool depth, client wait time, server connections, and saturation tracked against the real ceiling rather than the database max_connections. Most connection incidents are pooler incidents, and they look nothing alike from inside Postgres.
Recognised
- PgBouncer
- PgCat
- Odyssey
- Supavisor
- RDS Proxy
- pgagroal
- Pgpool
- None
Dimension 04
Backup and recovery
A backup nobody has restored is a hypothesis.
How it is detected. Process inventory and the tool’s own catalog or repository state.
What you get. Backup age, chain continuity, archive lag and retention against the recovery objective you declared, so a broken WAL archive surfaces before the restore does.
Recognised
- pgBackRest
- Barman
- WAL-G
- WAL-E
- pgcopydb
- pg_dump only
- Managed cloud backup
- None
Dimension 05
Replication
Physical, logical, or something further out on the spectrum.
How it is detected. Replication and subscription catalogs, plus the extension inventory for anything beyond the built-in paths.
What you get. Lag in the units each engine actually reports, slot health and retained write-ahead log, subscription conflicts, and the cross-region paths that only show up on the secondary.
Recognised
- Native physical
- Native logical
- pglogical
- Spock
- pgactive
- EDB Postgres Distributed
- PeerDB
- Debezium
- Sequin
- Slony
- Bucardo
- None
Dimension 06
Extensions
What is installed changes what can be measured and what can be advised.
How it is detected. The extension catalog, version by version, on every re-discovery.
What you get. Advisors degrade gracefully rather than failing: without the what-if extension the index advisor still ranks candidates by cost model, and it tells you what it could not do instead of quietly doing less.
Recognised
- pg_stat_statements
- auto_explain
- pgstattuple
- pg_cron
- pg_partman
- pgvector
- pgaudit
- PostGIS
- TimescaleDB
- Citus
- pg_wait_sampling
- pg_stat_kcache
- pg_qualstats
Dimension 07
Existing monitoring
You already run something. We would rather know than compete with it.
How it is detected. Process inventory and exporter endpoints.
What you get. Knowing what is already watching a cluster prevents duplicate alerting on the same failure, and tells us which signals you are already paying to collect twice.
Recognised
- Prometheus postgres_exporter
- pgwatch
- PoWA
- pgBadger
- pganalyze
- Datadog
- New Relic
- Dynatrace
- Nagios checks
- None
Why it matters
A tool that does not know the shape cannot know the failure
Wrong shape, silent gap
A monitor that assumes vanilla Postgres reports nothing useful on a distributed engine, and reports confidently wrong things on a managed one.
Right shape, right rule
Every detection rule declares the shapes it applies to. Rules that cannot be true on your topology are gated off rather than firing falsely.
Shape changes, you hear about it
Topology drift is its own event. A pooler that appeared, an orchestrator that changed, a replication path that was added.
Questions about discovery
Do I have to tell you what we run?
No. Discovery runs on first connection and re-runs on a schedule. You can correct anything it gets wrong, and the correction sticks, but the default is that nobody fills in a form.
What happens when we change something?
The next discovery pass notices. A changed topology raises its own event, so a pooler that appeared in front of a cluster, or an orchestrator that was swapped out, is something you find out about rather than something you remember.
What if a dimension is wrong?
Every detection carries a confidence score and a written rationale, so you can see which signal it used and why. Low confidence is surfaced rather than hidden, and you can override it.
What if we run something not on these lists?
The cluster still works. Unknown is a valid answer for every dimension, and the collectors that do not depend on it carry on. Tell us what you run and it usually becomes a detector.
Does this need extra access?
No. The same read-only monitoring role, plus whatever the tool in question already exposes, such as an orchestrator API or a pooler admin interface.
Tell us the strangest thing in your fleet.
We have probably met it. If we have not, that is the conversation we want to have.