BetterDB vs Percona PMM
PMM is an open-source monitoring platform for MySQL, PostgreSQL, MongoDB and, since version 3.5, Valkey and Redis. It gives you host metrics and ten Valkey dashboards fed by redis_exporter. What it does not have for Valkey is the query-level view it has for the other databases, or any detection beyond Grafana thresholds. BetterDB is that layer: the slow and oversized commands with the client behind them, an ACL audit trail, detectors for Valkey failure modes, forecasts and CVE checks. It plugs into PMM as a scrape target, so the result lands in the Grafana you already have.
BetterDB is a monitoring service for Valkey and Redis: one container from Docker, Helm or npx, or BetterDB Cloud. It connects as an ordinary client, keeps history, runs detectors and forecasts, and serves a UI, REST API and Prometheus endpoint on port 3001.
Which one do you need?
Stay on PMM alone when…
- You run MySQL, PostgreSQL or MongoDB next to Valkey and want one tool for all of them
- You need host metrics - CPU, disk, network - on the same dashboards
- Server-level vitals cover what you look at when Valkey misbehaves
Run both when…
- You want query-level detail for Valkey: PMM Query Analytics covers MySQL, PostgreSQL and MongoDB, not Valkey
- You want it in one place: PMM scrapes BetterDB as an external service, so its metrics land in the same Grafana
- PMM keeps the host and fleet context; BetterDB keeps slowlog, COMMANDLOG, client and ACL history and runs the detectors
Use BetterDB instead when…
- Valkey or Redis is the only database you run, and a PMM server is more than you want to operate
- You want Valkey alert rules ready-made - PMM ships instance-down templates for Valkey and leaves the rest for you to write in Grafana
- You run clusters or Sentinel and want every node discovered and failovers tracked for you
Side by side
| Capability | BetterDB | Percona PMM |
|---|---|---|
| What it is | A monitoring service for Valkey and Redis only | An open-source monitoring platform for MySQL, PostgreSQL, MongoDB, Valkey and Redis, with Grafana built in |
| How Valkey metrics are collected | Its own poller; the schedule is below | Upstream redis_exporter, bundled as valkey_exporter |
| Host metrics | No | Yes, through node_exporter in PMM Client |
| Other databases | No | MySQL, PostgreSQL, MongoDB and ProxySQL |
| Dashboards and rules | A built-in UI, ten Grafana dashboards you can import into PMM, and 19 Alertmanager rules | Ten Valkey/Redis dashboards: overview, clients, cluster, commands, load, memory, network, persistence, replication, slowlog |
| Slowlog | The entries, with arguments, duration and client; grouped by pattern, key prefix and client | Slowlog length and the configured thresholds |
| Query analytics | Yes, for Valkey and Redis: command patterns from SLOWLOG and COMMANDLOG over any time range, scrapeable into PMM | Not available for Valkey or Redis. The 3.5.0 release notes list it as planned |
| COMMANDLOG and CLUSTER SLOT-STATS | Entries grouped by pattern, and a heatmap of all 16,384 slots with per-slot key counts; both exported as betterdb_* series PMM can chart | Not on any PMM dashboard. The bundled exporter does emit COMMANDLOG entry counts |
| Cluster and Sentinel | One seed: auto-registration (opt-in) adds every node and keeps the list in sync; a Sentinel failover is picked up on the next 30-second sync | One pmm-admin add per node |
| ACL audit trail and client history | Both, persisted: ACL LOG by reason and user; CLIENT LIST snapshots every 60 seconds, rolled up for 90 days | Not available |
| Anomaly detection | Rolling five-minute baselines and more than 20 detectors correlated into named patterns with a diagnosis; the counts are exported so PMM alerting can route them | None - Grafana threshold alerts |
| Forecasting and capacity | Computed for you, per instance: time-to-limit for memory, CPU, ops/sec and fragmentation; a 0-100 scaling readiness score; a cache size simulator | Grafana predict_linear() if you write it |
| Security | Yes, for Valkey: server and module versions matched against five CVE feeds every 6 hours; config drift across replicas and shards; config hazard checks | Not for Valkey |
| Alerting | All Valkey-specific: HMAC-signed webhooks with retries and a delivery log, Slack and Discord formats, plus 19 Alertmanager rules | Grafana alerting on any metric, with 52 built-in templates. The two for Valkey and Redis cover instance-down |
| Advisors and backups | None | For MySQL, PostgreSQL and MongoDB. None for Valkey |
What it is
BetterDB
A monitoring service for Valkey and Redis only
Percona PMM
An open-source monitoring platform for MySQL, PostgreSQL, MongoDB, Valkey and Redis, with Grafana built in
How Valkey metrics are collected
BetterDB
Its own poller; the schedule is below
Percona PMM
Upstream redis_exporter, bundled as valkey_exporter
Host metrics
BetterDB
No
Percona PMM
Yes, through node_exporter in PMM Client
Other databases
BetterDB
No
Percona PMM
MySQL, PostgreSQL, MongoDB and ProxySQL
Dashboards and rules
BetterDB
A built-in UI, ten Grafana dashboards you can import into PMM, and 19 Alertmanager rules
Percona PMM
Ten Valkey/Redis dashboards: overview, clients, cluster, commands, load, memory, network, persistence, replication, slowlog
Slowlog
BetterDB
The entries, with arguments, duration and client; grouped by pattern, key prefix and client
Percona PMM
Slowlog length and the configured thresholds
Query analytics
BetterDB
Yes, for Valkey and Redis: command patterns from SLOWLOG and COMMANDLOG over any time range, scrapeable into PMM
Percona PMM
Not available for Valkey or Redis. The 3.5.0 release notes list it as planned
COMMANDLOG and CLUSTER SLOT-STATS
BetterDB
Entries grouped by pattern, and a heatmap of all 16,384 slots with per-slot key counts; both exported as betterdb_* series PMM can chart
Percona PMM
Not on any PMM dashboard. The bundled exporter does emit COMMANDLOG entry counts
Cluster and Sentinel
BetterDB
One seed: auto-registration (opt-in) adds every node and keeps the list in sync; a Sentinel failover is picked up on the next 30-second sync
Percona PMM
One pmm-admin add per node
ACL audit trail and client history
BetterDB
Both, persisted: ACL LOG by reason and user; CLIENT LIST snapshots every 60 seconds, rolled up for 90 days
Percona PMM
Not available
Anomaly detection
BetterDB
Rolling five-minute baselines and more than 20 detectors correlated into named patterns with a diagnosis; the counts are exported so PMM alerting can route them
Percona PMM
None - Grafana threshold alerts
Forecasting and capacity
BetterDB
Computed for you, per instance: time-to-limit for memory, CPU, ops/sec and fragmentation; a 0-100 scaling readiness score; a cache size simulator
Percona PMM
Grafana predict_linear() if you write it
Security
BetterDB
Yes, for Valkey: server and module versions matched against five CVE feeds every 6 hours; config drift across replicas and shards; config hazard checks
Percona PMM
Not for Valkey
Alerting
BetterDB
All Valkey-specific: HMAC-signed webhooks with retries and a delivery log, Slack and Discord formats, plus 19 Alertmanager rules
Percona PMM
Grafana alerting on any metric, with 52 built-in templates. The two for Valkey and Redis cover instance-down
Advisors and backups
BetterDB
None
Percona PMM
For MySQL, PostgreSQL and MongoDB. None for Valkey
Checked against PMM 3.10.0 and BetterDB 0.54.0, November 2026. Spot something out of date? Tell us and we will fix it.
Sources: PMM repository · PMM 3.5.0 release notes · Connecting Valkey and Redis · External services
What BetterDB adds on top of PMM
PMM gives Valkey the same treatment as any exporter target. Three things that need a tool built for Valkey, each with what it looks like in PMM once scraped.
Query analytics for Valkey
The stored SLOWLOG and COMMANDLOG entries are grouped by command pattern, key prefix and client - for Valkey what PMM Query Analytics gives you for MySQL and Postgres. The pattern series arrive in PMM through the external-service scrape.
Example
betterdb_slowlog_pattern_count{pattern="HGETALL session:*",connection="cache-eu-1"} 24
betterdb_commandlog_large_reply_by_pattern{pattern="SMEMBERS tags:*"} 7Detectors, not thresholds
A rolling five-minute baseline per metric, spikes and drops scored against it and confirmed over three consecutive samples, then correlated within five seconds into a named pattern with a diagnosis. The counts are exported, so a Grafana alert in PMM can fire on a critical pattern without you writing the threshold.
Example
MEMORY_PRESSURE critical cache-eu-1 Memory pressure detected with potential evictions memory_used z=3.4 evicted_keys z=2.9 fragmentation_ratio 1.8
Capacity you can plan around
A time-to-limit per instance from a rolling 6-hour regression - the same math as predict_linear(), computed per instance and exported, with a default alert when the limit is under two hours away - plus a cache size simulator that samples the keyspace and projects when you hit maxmemory over 30 days, 90 days or 6 months.
Example
betterdb_metric_forecast_time_to_limit_seconds{metric_kind="usedMemory",connection="cache-eu-1"} 5400Adding BetterDB to PMM
PMM accepts any Prometheus endpoint as an external service. On a node that runs pmm-agent next to BetterDB:
pmm-admin add external \ --service-name=betterdb \ --listen-port=3001 \ --metrics-path=/api/prometheus/metrics \ --scheme=http
If BetterDB runs on a host without pmm-agent, use pmm-admin add external-serverless with --host instead. Either way the betterdb_* series end up in the metrics store PMM already queries: slowlog patterns, COMMANDLOG large requests and replies by pattern, per-slot key counts, anomaly events by severity and the forecast time-to-limit.
Then import BetterDB's Query Patterns and Anomalies dashboards into PMM's Grafana. They sit next to the stock Valkey dashboards and read different metric families, so nothing overlaps. The step-by-step version is in the PMM integration guide linked below.
How BetterDB runs
The operational facts behind every row above, taken from BetterDB 0.54.0.
What it is
One Node.js service in one container (310 MB image) from Docker, Helm or npx, or hosted as BetterDB Cloud. It serves the web UI, the REST API and the Prometheus endpoint on port 3001, and can push metrics and events over OTLP. The Helm chart requests 100m CPU and 256 MiB with a 1 CPU, 1 GiB limit, and runs one replica: the process holds the anomaly baselines and capture sessions, and the chart notes that more replicas only make sense with Postgres and are not load-balanced work.
How it connects
As an ordinary client. Every poller shares one long-lived connection per monitored instance, named BetterDB-Monitor in CLIENT LIST, plus a few helpers: a discovery connection on clusters and Sentinels, a scratch connection for key sampling on databases other than 0, and a dedicated socket for each MONITOR capture. TLS is per connection. For instances with no inbound path, such as ElastiCache or Memorystore, the BetterDB agent runs inside your network and connects outbound over WebSocket to BetterDB Cloud or to your self-hosted BetterDB. Nothing is installed on the Valkey nodes.
Storage and retention
History is in memory by default and lost on restart. Set STORAGE_TYPE to sqlite or postgres and everything it stores - slowlog and COMMANDLOG entries, client snapshots, anomaly events, captures - is kept until you set a retention window in Settings or LOCAL_RETENTION_DAYS. Client-list snapshots are also rolled into 5-minute buckets kept 90 days. SQLite means one replica on a volume, and the -no-ai image variant ships without it; Postgres is the choice when the history must outlive the pod.
When BetterDB is down
Polling, detectors, forecasts and webhooks stop, and if BetterDB is your only Prometheus source, so do your Valkey metrics. Alert on up for the betterdb scrape job, and on betterdb_poll_stale, which is 1 when a connection has had no successful poll within the staleness bound (15 seconds by default). Self-hosted installs send usage telemetry to PostHog EU - version, deployment mode and events such as app start and page views - unless BETTERDB_TELEMETRY=false; an offline license forces it off, and CVE_ENABLED=false removes the only other outbound call.
What it needs from your database
Read-only. The base user below covers monitoring; it has no CONFIG SET, no KEYS, no FLUSH and no RESET commands. Key sampling adds a read-only key pattern with SCAN and MEMORY USAGE, and capture sessions add +monitor, both opt-in.
ACL SETUSER betterdb reset on >CHANGE_ME -@all +ping +info +select +client|setname +client|getname +client|list +client|no-touch +config|get +slowlog|get +slowlog|len +commandlog|get +commandlog|len +latency|latest +latency|histogram +latency|history +latency|doctor +memory|stats +memory|doctor +acl|whoami +acl|log +role +cluster|info +cluster|nodes +cluster|shards +cluster|slot-stats +cluster|myid +command|info +dbsize +lastsave +time +module|list
- Deny CONFIG GET and config drift, hazard checks and scaling readiness skip the connection.
- Deny CLIENT LIST and client pages and client history are unavailable.
- Deny ACL LOG and the audit trail is unavailable.
- Deny SLOWLOG or COMMANDLOG and those pages are unavailable; everything else keeps running.
- Deny MONITOR and capture sessions cannot start. It is not in the base line above.
What it runs, and how often
All on the one shared connection. KEYS is never used. MONITOR runs only inside a capture session you start, schedule or arm on an anomaly: 30 seconds by default, capped at 50 MB or 5 million lines, refused while memory is above 85% or a failover is in progress, with MONITOR_REDACT_VALUES to scrub values.
INFO
Every 1s for anomaly baselines, 5s for metrics. Both intervals configurable. The 5s loop also reads INFO keysizes and two cached CONFIG GET keys for persistence checks.
PING
Every 10s. Health check.
SLOWLOG GET 128; COMMANDLOG GET 128 for slow, large-request and large-reply
Every 30s. COMMANDLOG on Valkey 8.1+ only, three calls.
CLIENT LIST, ACL LOG 100, LATENCY LATEST and HISTOGRAM, INFO commandstats and latencystats
Every 60s. CLIENT LIST is unbounded; cost grows with connected clients.
CLUSTER INFO, NODES, SLOT-STATS (top 100)
Every 5s. Cluster connections only.
CLUSTER NODES or SENTINEL MASTERS for auto-registration
Every 30s. Only when auto-registration is turned on.
CONFIG GET for a short allowlist of keys, one per call; ACL LIST
Every 60 anomaly polls (about 60s). Config drift and hazard checks; skipped if denied. Never CONFIG GET *.
SCAN sample of 10,000 keys with TYPE, TTL, MEMORY USAGE and OBJECT FREQ or IDLETIME
Every 5 min. Key analytics; needs the optional read-only key rules.
CVE dataset refresh
Every 6h. Outbound to GitHub, NVD, MITRE, CISA and FIRST (EPSS); CVE_ENABLED=false turns it off.
Full references: minimum ACL · configuration and retention · capture sessions · Kubernetes guide
Wire the two together
The BetterDB docs have a step-by-step guide for PMM, and the public Grafana demo shows the dashboards you would be importing.
Other comparisons: redis_exporter · Prometheus and Grafana · OTel Redis receiver · Datadog · APM tools · Valkey Admin · Redis Insight · CloudWatch · cloud monitoring · RedisShake · ElastiCache migration
FAQ
Does Percona PMM support Valkey?
Yes. Native Valkey and Redis monitoring arrived in PMM 3.5.0 in November 2025. You add an instance with pmm-admin add valkey, and PMM provides ten dashboards for it.
Does PMM have Query Analytics for Valkey or Redis?
No. Query Analytics covers MySQL, PostgreSQL and MongoDB. The PMM 3.5.0 release notes say support for Valkey and Redis is planned and point to the built-in SLOWLOG command in the meantime. The PMM Slowlog dashboard shows how many entries the slowlog holds and how it is configured, not the entries. BetterDB stores the entries and groups them by pattern, key prefix and client.
Which exporter does PMM use for Valkey?
The upstream oliver006/redis_exporter, installed under the name valkey_exporter. It is not a fork, so its metrics are the redis_* series described on our redis_exporter comparison page.
Can PMM scrape BetterDB?
Yes. Add BetterDB's Prometheus endpoint with pmm-admin add external, or add a scrape job for /api/prometheus/metrics. The betterdb_* metrics then appear in PMM's Grafana alongside its own.
Does PMM alert on anomalies for Valkey?
PMM alerting is Grafana alerting: you set thresholds on any metric, and two built-in templates cover a Valkey instance being down. BetterDB scores each metric against a rolling five-minute baseline per instance, correlates the anomalies into patterns with a diagnosis, and exports the counts as metrics PMM can alert on too.
Should I replace PMM with BetterDB?
Usually not. If you already run PMM for other databases, keep it and add BetterDB for the Valkey query-level view, the detectors and the forecasts. BetterDB on its own makes sense when Valkey or Redis is the only database you monitor.
Deciding between more tools? When should you use BetterDB? →
Run it locally in one command
docker run -d -p 3001:3001 betterdb/monitor:latest
Then open http://localhost:3001 - see the Docker guide.
See it on your own data
BetterDB Cloud runs the service and its storage for you. Or self-host it next to the tools you already use.