Percona Monitoring and Management

Last reviewed Sep 13, 2026 · 778 words

Two gigabytes of RAM is the minimum for PMM Server, and it is worth every megabyte in exactly one situation: you run a database that people would be upset to see slow, and you do not know which queries are making it slow. Query Analytics answers that question per query, per fingerprint, with the execution plan a click away. If your databases are the SQLite behind a bookmark app, close this tab; a node exporter and one Grafana dashboard cost 200 MB and tell you enough.

Query Analytics is the product; everything else is Grafana

Under the hood PMM is Grafana with a bundled time-series store and a ClickHouse instance for query data. The 40-odd prebuilt dashboards (InnoDB buffer pool, PostgreSQL vacuum activity, MongoDB replica set lag) are good, but you can assemble equivalents from community dashboards with Grafana and the standard exporters in an afternoon. What you cannot assemble is QAN: it ingests the slow log or performance_schema on MySQL, pg_stat_statements on PostgreSQL, and the profiler on MongoDB, normalises every query into a fingerprint, and ranks them by total time, rows examined and lock time over any window you choose. That is the feature that turns "the app is slow" into "this one SELECT without an index is 60% of load."

Built-in alerting comes with templates for the obvious conditions (replication lag, connections near max, disk filling), and it is ordinary Grafana alerting underneath, so routing to Slack or email is the standard flow.

One server container, one client per database host

PMM Server ships as a single image with everything inside and persists to one volume:

services:
  pmm-server:
    image: percona/pmm-server:3
    ports:
      - "443:8443"
    volumes:
      - pmm-data:/srv
    restart: unless-stopped

volumes:
  pmm-data:

Log in at https://host as admin / admin and change the password immediately. Then install the pmm-client package on each database host (or run pmm-client as a sidecar container) and register it:

pmm-admin config --server-insecure-tls \
  --server-url=https://admin:[email protected]:443
pmm-admin add mysql --username=pmm --password='...' \
  --query-source=perfschema mysql-main 127.0.0.1:3306
pmm-admin add postgresql --username=pmm --password='...' \
  pg-main 127.0.0.1:5432

Create a dedicated pmm user in each database with the read and process privileges the docs list, and enable pg_stat_statements on PostgreSQL before adding it, or QAN shows an empty table. The first hour of data is thin; give it a day before judging the dashboards.

Budget 2 GB, expect 4, and watch the volume

The 2,048 MB floor is real for a single-node lab. Monitoring 5 busy instances with the default 30-day retention pushes the container past 3 GB, and the /srv volume grows with query variety more than with query volume: an ORM generating thousands of distinct fingerprints fills ClickHouse faster than a hand-written app doing millions of identical queries. Set the metrics retention in the settings page to what you actually look at, 7 to 14 days for a homelab, and snapshot the volume before every major upgrade. Upgrading PMM Server is a pull-and-recreate of the container on the same volume; the client version should trail or match the server, never lead it.

Databases only, so it is your second monitoring system

PMM does not monitor hosts, containers, or services in any general sense. It exposes node metrics for the machines its clients run on, but it is not where you check whether the reverse proxy is up. Run it next to, not instead of, Prometheus or Netdata, and accept two Grafana instances or point external Grafana at PMM's data source. That duplication is the main reason small teams stop at exporters, and it is a fair reason.

Where PMM earns its place is replacing a paid database observability tool: it is the direct self-hosted answer to Datadog Database Monitoring and SolarWinds DPA, and for a team paying per host for those, an AGPL-3.0 tool with 1,102 stars and a company behind it is the safe choice, not the adventurous one.

What I'd do

Running one or more MySQL, PostgreSQL or MongoDB instances that serve real users: deploy PMM Server on a box with 4 GB free, register every instance with QAN enabled, cut retention to 14 days, and spend one evening a month reading the top 10 queries. That evening usually pays for the RAM. Running databases nobody would notice slowing down: skip it, add postgres_exporter or mysqld_exporter to your existing Prometheus, and import one community dashboard.