BetterDB vs Valkey Admin
Valkey Admin is the Valkey project's own tool for working on a cluster: browse keys, run commands, see the topology and the hot slots. BetterDB is a monitoring service that keeps recording when nobody is looking - each SLOWLOG and COMMANDLOG entry it reads every 30 seconds with the client behind it, each ACL denial, a client-list snapshot every minute - and tells you when something changes: a spike against the instance's own baseline, a failover, a forecast crossing its limit, a new CVE for your version. They overlap on dashboards and command logs, and differ on what happens after you close the tab.
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?
Use Valkey Admin when…
- You want to browse, edit and delete keys, or run commands with autocomplete
- You want a desktop app on macOS or Linux for the cluster in front of you
- You are inspecting right now: topology, hot slots, big keys, the current command log
Run both when…
- Valkey Admin is your hands-on console and BetterDB is the always-on recorder
- You want alerts, anomaly detection and Prometheus metrics today - Valkey Admin has none of them yet
Use BetterDB instead when…
- Collection has to keep running when nobody has the UI open
- You need the slow commands and large requests from last week, grouped by pattern and by client
- You run Redis, or Valkey older than 8.1 - Valkey Admin command logs need 8.1 or newer
- You need alerts, failover and split-brain detection, forecasts, CVE checks or an ACL audit trail
Side by side
| Capability | BetterDB | Valkey Admin |
|---|---|---|
| What it is | An always-on monitoring service with stored history, detectors and alerts | An administration and observability UI from the Valkey project, as a desktop app or a container |
| Key browser and editing | Not in the monitor - the BetterDB for Valkey VS Code extension covers it | Browse, search, edit, add and delete across data types, including JSON |
| Command console | A browser CLI with role-based command restrictions and an activity log | Send Command with autocomplete, history and result compare |
| Collection with the UI closed | Yes - it is a server process | Desktop: stops when the app closes. Docker: stops shortly after the last browser disconnects, unless the connection is preconfigured on the server |
| History | In memory by default and lost on restart. With SQLite or Postgres, kept until you set a retention window | CPU and memory charts from local files - about a day per node at the default settings, configurable |
| Slow commands and large requests | Every entry it reads, stored with its client and grouped by pattern, key prefix and client, for any time range | COMMANDLOG slow, large-request and large-reply views showing the latest snapshot across nodes (Valkey 8.1+) |
| Hot keys | Keys, not slots: a 10,000-key sample every 5 minutes ranked by access frequency, top 50 per database stored, with rank movement over time | Hot slots from CLUSTER SLOT-STATS, or MONITOR sampling as a fallback |
| Big keys | From the same sample, continuously: memory and cardinality of the largest keys, exported as metrics | On-demand scan, top 50 keys by memory |
| Cluster topology | Topology graph, a heatmap of all 16,384 slots, and auto-registration (opt-in) that adds every node from one seed and keeps the list in sync | Node table with memory, CPU, ops/sec, hit ratio and connections per primary |
| Sentinel | With auto-registration on, primaries and replicas are discovered through Sentinel; a failover is picked up on the next 30-second sync, with history kept | Not mentioned in its documentation |
| Traffic capture | Stored sessions, not sampling: opt-in MONITOR captures on demand, scheduled, or armed for the next recurrence of an anomaly; 30 seconds by default, capped and health-gated | MONITOR sampling for hot keys |
| Anomaly detection and forecasting | A rolling five-minute baseline per metric with more than 20 detectors correlated into named patterns; time-to-limit forecasts for memory, CPU, ops/sec and fragmentation | None |
| Alerts | HMAC-signed webhooks with retries, Slack and Discord formats, and an Alertmanager rules file | None yet - there is an open issue |
| Security checks | Server and module versions matched against five CVE feeds every 6 hours; config drift across replicas and shards; config hazard checks | None |
| Prometheus and OpenTelemetry | Both: 110+ metrics on a Prometheus endpoint, OTLP export of metrics and events, OTLP trace ingest | Neither yet - Prometheus has an open issue |
| ACL audit and client history | Both, persisted: ACL LOG by reason and user; CLIENT LIST snapshots every 60 seconds, rolled up for 90 days | Out of scope for an admin tool |
| Redis support | Valkey and Redis | Valkey; Redis up to 7.2.4 |
What it is
BetterDB
An always-on monitoring service with stored history, detectors and alerts
Valkey Admin
An administration and observability UI from the Valkey project, as a desktop app or a container
Key browser and editing
BetterDB
Not in the monitor - the BetterDB for Valkey VS Code extension covers it
Valkey Admin
Browse, search, edit, add and delete across data types, including JSON
Command console
BetterDB
A browser CLI with role-based command restrictions and an activity log
Valkey Admin
Send Command with autocomplete, history and result compare
Collection with the UI closed
BetterDB
Yes - it is a server process
Valkey Admin
Desktop: stops when the app closes. Docker: stops shortly after the last browser disconnects, unless the connection is preconfigured on the server
History
BetterDB
In memory by default and lost on restart. With SQLite or Postgres, kept until you set a retention window
Valkey Admin
CPU and memory charts from local files - about a day per node at the default settings, configurable
Slow commands and large requests
BetterDB
Every entry it reads, stored with its client and grouped by pattern, key prefix and client, for any time range
Valkey Admin
COMMANDLOG slow, large-request and large-reply views showing the latest snapshot across nodes (Valkey 8.1+)
Hot keys
BetterDB
Keys, not slots: a 10,000-key sample every 5 minutes ranked by access frequency, top 50 per database stored, with rank movement over time
Valkey Admin
Hot slots from CLUSTER SLOT-STATS, or MONITOR sampling as a fallback
Big keys
BetterDB
From the same sample, continuously: memory and cardinality of the largest keys, exported as metrics
Valkey Admin
On-demand scan, top 50 keys by memory
Cluster topology
BetterDB
Topology graph, a heatmap of all 16,384 slots, and auto-registration (opt-in) that adds every node from one seed and keeps the list in sync
Valkey Admin
Node table with memory, CPU, ops/sec, hit ratio and connections per primary
Sentinel
BetterDB
With auto-registration on, primaries and replicas are discovered through Sentinel; a failover is picked up on the next 30-second sync, with history kept
Valkey Admin
Not mentioned in its documentation
Traffic capture
BetterDB
Stored sessions, not sampling: opt-in MONITOR captures on demand, scheduled, or armed for the next recurrence of an anomaly; 30 seconds by default, capped and health-gated
Valkey Admin
MONITOR sampling for hot keys
Anomaly detection and forecasting
BetterDB
A rolling five-minute baseline per metric with more than 20 detectors correlated into named patterns; time-to-limit forecasts for memory, CPU, ops/sec and fragmentation
Valkey Admin
None
Alerts
BetterDB
HMAC-signed webhooks with retries, Slack and Discord formats, and an Alertmanager rules file
Valkey Admin
None yet - there is an open issue
Security checks
BetterDB
Server and module versions matched against five CVE feeds every 6 hours; config drift across replicas and shards; config hazard checks
Valkey Admin
None
Prometheus and OpenTelemetry
BetterDB
Both: 110+ metrics on a Prometheus endpoint, OTLP export of metrics and events, OTLP trace ingest
Valkey Admin
Neither yet - Prometheus has an open issue
ACL audit and client history
BetterDB
Both, persisted: ACL LOG by reason and user; CLIENT LIST snapshots every 60 seconds, rolled up for 90 days
Valkey Admin
Out of scope for an admin tool
Redis support
BetterDB
Valkey and Redis
Valkey Admin
Valkey; Redis up to 7.2.4
Checked against Valkey Admin v1.3.0 and BetterDB 0.54.0, November 2026. Disclosure: BetterDB's founder has contributed to Valkey Admin. Spot something out of date? Tell us and we will fix it.
Sources: Valkey Admin repository · Metrics retention settings · Collector lifecycle · Limitations · Alerts issue · Prometheus issue
What an admin console cannot do
Three things that depend on a process that keeps running and keeps state.
History you can search
Valkey Admin shows the command log as it is right now. BetterDB polls SLOWLOG GET and COMMANDLOG GET every 30 seconds and stores each entry with its arguments, duration, client address and name, fingerprinted into patterns, so the 3am spike is still there in the morning with the client that caused it.
Example
HGETALL session:* 24 entries avg 1.25 s 18.8% of slow time from 10.0.4.17 (checkout-api) last seen 03:12:40
Something that pages you
Valkey Admin has no alerting yet. BetterDB scores every metric against a rolling five-minute baseline, confirmed over three consecutive samples, correlates what moved together into a named pattern with a diagnosis, and delivers it as an HMAC-signed webhook with retries and a delivery log, to Slack, Discord or anything that takes JSON.
Example
POST /hooks/valkey X-Webhook-Event: anomaly.detected X-Webhook-Signature: sha256=…
{ "pattern": "CONNECTION_LEAK", "severity": "warning", "connection": "cache-eu-1" }Topology that follows the cluster
With auto-registration on, add one node or one Sentinel and every primary and replica is registered and kept in sync every 30 seconds. Nodes that leave are retired with their history intact; a Sentinel failover is picked up on the next 30-second topology sync and roles change in place, so names and history survive the switch.
Example
Sentinel group sessions primary changed 10.0.4.11:6379 → 10.0.4.12:6379 roles refreshed in place, ids and history kept
A console and a recorder
Valkey Admin is built for the moment you sit down at a cluster: see the topology, open a key, run a command, check what the command log holds right now. Its collectors are tied to that session. On the desktop app they stop when you quit. In Docker they stop shortly after the last browser tab disconnects, unless the connection was preconfigured on the server.
BetterDB is built for the moment you were not there. It polls continuously as a service, stores the entries it reads, scores each metric against the instance's own recent baseline, and alerts when the picture changes. With SQLite or Postgres configured, the history is still there in the morning, together with the anomaly that flagged it and the clients that were connected.
That is why the two overlap less than the feature lists suggest, and why running both is a reasonable setup.
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
See the recorder side
The public Grafana demo shows the series BetterDB keeps: query patterns, ACL denials, client connections and anomalies, from several live instances.
Other comparisons: redis_exporter · Prometheus and Grafana · OTel Redis receiver · Datadog · APM tools · Percona PMM · Redis Insight · CloudWatch · cloud monitoring · RedisShake · ElastiCache migration
FAQ
Is Valkey Admin a monitoring tool?
Partly. It has a dashboard, command logs, hot keys and a topology view, and it describes itself as an administration tool. As of v1.3.0 it has no alerting, no anomaly detection and no Prometheus or OpenTelemetry export; alerting and Prometheus are tracked as open issues.
Does Valkey Admin keep history?
For CPU and memory, yes. It writes samples to local files with a disk budget, which at the default settings holds about a day per node and can be raised. The command log views show the latest snapshot, not a searchable history. BetterDB stores every slowlog and COMMANDLOG entry it reads; a burst that overflows the buffer between two polls is lost to any tool.
Can BetterDB browse or edit keys?
Not in the monitor. Use Valkey Admin for that, or the BetterDB for Valkey VS Code extension. BetterDB does include a browser CLI, with role-based restrictions so members cannot run CONFIG, ACL or DEBUG, and an activity log of every command.
Does Valkey Admin work with Redis?
Its documentation lists compatibility with Redis up to 7.2.4. The command log views need Valkey 8.1 or newer, because they are built on COMMANDLOG. BetterDB polls both SLOWLOG and COMMANDLOG on Valkey 8.1+, and SLOWLOG alone on Redis and older Valkey.
Does Valkey Admin support Sentinel?
Its documentation and limitations page do not mention Sentinel. With auto-registration on, BetterDB discovers primaries and replicas through Sentinel, registers them, and picks up a failover on its next 30-second topology sync, changing roles in place so names and history survive the switch.
Can I use Valkey Admin and BetterDB together?
Yes. Both connect as ordinary clients, so each adds its own polling load and neither depends on the other. One way to split it: Valkey Admin for hands-on work, BetterDB for continuous history, detection and alerts.
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.