Percona Monitoring and Management (PMM) is an open source database monitoring, observability and management tool, licensed AGPL-3.0, that gives MySQL, MongoDB, PostgreSQL, Valkey and Redis operators a single pane of glass over database performance, security and availability.

What it is

Percona Monitoring and Management is a client-server monitoring platform written in Go and distributed primarily as a Docker image. The server component runs as the percona/pmm-server:3 container with persistent state held in the pmm-data volume, and it exposes a web interface on port 8443 that is published to HTTPS on the host. Client components connect the databases to be observed back to that server. The project lives in the Percona ecosystem and carries the database, database-management, monitoring, observability and pmm topics on GitHub.

The concrete problem it solves is fragmentation. Teams running more than one database engine normally end up consulting a different set of dashboards, metrics endpoints and alerting rules for each engine. PMM consolidates MySQL, MongoDB, PostgreSQL, Valkey and Redis into one interface, so performance data, alerts and advisor findings for all of them are reviewed in the same place rather than gathered engine by engine. It also moves beyond passive graphing by shipping built-in Advisors that run regular checks against connected databases and flag potential security threats, performance degradation, data loss and data corruption.

Key capabilities

• Server deployment from the percona/pmm-server:3 Docker image, backed by the pmm-data volume mounted at /srv.
• Web interface published with --publish 443:8443, reachable in a browser at the server host, defaulting to https://localhost.
• Default credentials of username admin and password admin on first login.
• Customizable dashboards with real-time alerting for database performance.
• Drill-down analysis that zooms from node level to single query level for troubleshooting and optimization.
• Built-in Advisors performing scheduled checks for security threats, performance degradation, data loss and data corruption.
• Coverage of five engines in one tool: MySQL, MongoDB, PostgreSQL, Valkey and Redis.

Who uses it and how

• Database reliability and operations teams running more than one engine, who need one dashboard set instead of per-engine tooling.
• Teams troubleshooting incidents, using query-level drill-down to find root cause faster.
• Organizations operating business-critical database environments spread across hybrid infrastructure, from cloud providers to bare metal.
• Security-conscious operators who rely on the Advisors' recurring checks rather than ad hoc audits.
• Operations groups with mission-critical monitoring deployments, which have the option of commercial enterprise-grade support from Percona alongside the community forum.

Getting started

Run docker pull percona/pmm-server:3, create the volume with docker volume create pmm-data, then start the server with docker run --detach --restart always --publish 443:8443 --volume pmm-data:/srv --name pmm-server percona/pmm-server:3. Open the host in a browser and log in with admin / admin. The README points to the separate "About PMM installation" documentation page for other installation methods.

How it compares

No list of paid products that this project replaces is provided in the facts, and no comparable monitoring tools are named there either. On the available evidence, it stands alone in this registry.

When to use it — and when not to

A self-hoster must run and maintain the Docker server container and its pmm-data volume, so a working container runtime and persistent storage are prerequisites, and the documented quickstart leaves TLS termination and authentication hardening to the operator. Teams that want only a single-engine agent, or that will not accept an AGPL-3.0 copyleft licence, should look elsewhere. The README excerpt is thin beyond the quickstart: it defers installation detail to external documentation, and the repository shows 240 open issues, so prospective adopters should expect an actively worked backlog rather than a quiet one.

$ docker pull percona/pmm-server:3

$ docker volume create pmm-data

$ docker run --detach --restart always \
  --publish 443:8443 \
  --volume pmm-data:/srv \
  --name pmm-server \
  percona/pmm-server:3