Query performance and health monitoring for MySQL and PostgreSQL
| Database | Key metrics | Alert examples |
|---|---|---|
| MySQL | Queries/sec, connections, InnoDB, replication | Connection exhaustion, replication lag |
| PostgreSQL | Transactions, locks, vacuum, connections | Lock contention, vacuum failures |
Questions answered
| With Database Observability, you can answer… |
|---|
| Which queries are slowest in my PostgreSQL database? |
| Is my MySQL replication falling behind? |
| How many connections does my database have vs. its limit? |
| When will my database run out of disk space? |
| What’s causing lock contention in PostgreSQL? |
Problems solved
| Problem | Solution |
|---|---|
| Database issues discovered when users complain | Proactive alerts catch problems early. |
| No visibility into query performance | Performance dashboards show slow queries. |
| Replication failures surprise the team | Lag monitoring with alerts |
| Connection pool exhaustion crashes apps | Connection monitoring prevents outages. |
What you get
| Component | Description |
|---|---|
| Performance dashboard | Query rates, latency, throughput |
| Connection monitoring | Pool usage, active connections |
| Storage metrics | Disk usage, table sizes, growth |
| Replication health | Lag, sync status, failover readiness |
Other databases? For MongoDB, Redis, Elasticsearch, and more, use Integrations for pre-built dashboards or data source connections to query them directly. Database Observability is also expanding — native support for more databases is coming.
Script
Databases are often the source of performance problems, and they’re often the last place teams look. Database Observability changes that.
Database Observability is purpose-built for MySQL and PostgreSQL. You get visibility into what matters: queries per second, connection pools, replication status, storage consumption.
These are the things that tell you if your database is happy or about to fall over.
Think about the questions this answers. Which queries are slowest? Is replication falling behind? How close am I to exhausting my connection pool? When will my database run out of disk space?
The real value here is being proactive instead of reactive. Without database observability, you typically discover problems when users start complaining.
With it, you catch issues before they impact anyone. Your alerts fire when replication lag crosses a threshold, not when someone notices stale data.
For other databases like MongoDB, Redis, or Elasticsearch, you can use integrations for pre-built monitoring or data source connections to query them directly. And Database Observability itself is expanding — support for more databases is on the way.