BetterDB vs built-in cloud monitoring
Every managed Valkey or Redis service - ElastiCache, Memorystore, Azure Managed Redis, DigitalOcean, Aiven, Upstash - comes with charts: CPU, memory, connections, hit rate. They tell you the instance is healthy. They do not tell you which command was slow, which client sent it, whether the last five minutes look like the five before, or when you will hit maxmemory. BetterDB connects as an ordinary client and adds that layer, within whatever commands the provider allows, and gives you one view across every provider and your self-hosted nodes. For VPC-only services its agent runs inside your network and dials out.
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 with the built-in monitoring when…
- You want infrastructure health: CPU, memory, replication, failovers
- Threshold alerts through the cloud's own monitoring are enough
- You would rather not run or connect anything else
Run both when…
- The console shows that memory or latency moved, and you need the commands and clients behind it
- You want the provider for infrastructure events and BetterDB for what happened inside the database
- You want a baseline per instance and a forecast, not a static threshold
Make BetterDB the main view when…
- You run Valkey on more than one provider, or managed and self-hosted, and want one place to look
- You need history for longer than the provider keeps it
- The provider's console shows host metrics only
- You want to know when you run out of memory and what node size fixes it
Side by side
| Capability | BetterDB | Built-in provider monitoring |
|---|---|---|
| Infrastructure metrics (CPU, memory, network, replication) | Database-level only | Yes - included with the service |
| Provider events (failovers, maintenance, quotas) | Role changes and failovers detected from the database itself; no provider events | Yes |
| Slow commands | The entries, with arguments, duration and client, grouped by pattern - wherever the provider permits SLOWLOG | None of the six shows slowlog entries |
| Per-command stats | Calls and average latency per command, stored, on every provider | Memorystore for Valkey only |
| Client visibility | Every client: CLIENT LIST snapshots every 60 seconds by name and user, rolled up for 90 days | Connected-client counts |
| ACL audit trail | Where ACL LOG is allowed. Memorystore, DigitalOcean and Aiven block it | Denied-command counters on Memorystore; none elsewhere |
| Anomaly detection | A rolling five-minute baseline per metric and more than 20 detectors correlated into named patterns with a diagnosis, from INFO alone | Threshold alerts through the cloud's monitoring service |
| Forecasting and sizing | Time-to-limit for memory, CPU, ops/sec and fragmentation per instance, and a cache size simulator that recommends a node size on ElastiCache, MemoryDB, Memorystore or Azure Cache for Redis | None of the six |
| Security | CVE scan of the server version every 6 hours; config hazard checks where CONFIG GET is allowed | Patching is the provider's job; no per-version CVE view |
| Traffic capture | Opt-in MONITOR captures where the provider permits MONITOR; 30 seconds by default, capped and health-gated | None |
| History | In memory by default and lost on restart. With SQLite or Postgres, kept until you set a retention window; client snapshots rolled up for 90 days | Six weeks on Google Cloud, 93 days on Azure, 14 days of charts on DigitalOcean |
| Across providers | One fleet view for every provider and for self-hosted, with status, memory, ops/sec and role per instance | One console per cloud |
Infrastructure metrics (CPU, memory, network, replication)
BetterDB
Database-level only
Built-in provider monitoring
Yes - included with the service
Provider events (failovers, maintenance, quotas)
BetterDB
Role changes and failovers detected from the database itself; no provider events
Built-in provider monitoring
Yes
Slow commands
BetterDB
The entries, with arguments, duration and client, grouped by pattern - wherever the provider permits SLOWLOG
Built-in provider monitoring
None of the six shows slowlog entries
Per-command stats
BetterDB
Calls and average latency per command, stored, on every provider
Built-in provider monitoring
Memorystore for Valkey only
Client visibility
BetterDB
Every client: CLIENT LIST snapshots every 60 seconds by name and user, rolled up for 90 days
Built-in provider monitoring
Connected-client counts
ACL audit trail
BetterDB
Where ACL LOG is allowed. Memorystore, DigitalOcean and Aiven block it
Built-in provider monitoring
Denied-command counters on Memorystore; none elsewhere
Anomaly detection
BetterDB
A rolling five-minute baseline per metric and more than 20 detectors correlated into named patterns with a diagnosis, from INFO alone
Built-in provider monitoring
Threshold alerts through the cloud's monitoring service
Forecasting and sizing
BetterDB
Time-to-limit for memory, CPU, ops/sec and fragmentation per instance, and a cache size simulator that recommends a node size on ElastiCache, MemoryDB, Memorystore or Azure Cache for Redis
Built-in provider monitoring
None of the six
Security
BetterDB
CVE scan of the server version every 6 hours; config hazard checks where CONFIG GET is allowed
Built-in provider monitoring
Patching is the provider's job; no per-version CVE view
Traffic capture
BetterDB
Opt-in MONITOR captures where the provider permits MONITOR; 30 seconds by default, capped and health-gated
Built-in provider monitoring
None
History
BetterDB
In memory by default and lost on restart. With SQLite or Postgres, kept until you set a retention window; client snapshots rolled up for 90 days
Built-in provider monitoring
Six weeks on Google Cloud, 93 days on Azure, 14 days of charts on DigitalOcean
Across providers
BetterDB
One fleet view for every provider and for self-hosted, with status, memory, ops/sec and role per instance
Built-in provider monitoring
One console per cloud
Checked against each provider's public documentation and BetterDB 0.54.0, November 2026. We have not tested every command on every service; where the documentation is silent, the table below says so. Spot something out of date? Tell us and we will fix it.
Sources: ElastiCache restricted commands · Memorystore for Valkey commands · Memorystore for Valkey metrics · Azure Managed Redis overview · Azure Managed Redis metrics · DigitalOcean Valkey limits · DigitalOcean Valkey monitoring · Aiven restricted commands · Aiven monitoring · Upstash Redis docs
What BetterDB adds on any provider
Three things that work from INFO and the client connection alone, so they are available even where the provider blocks SLOWLOG and ACL.
A baseline for this instance
A rolling five-minute baseline per metric (300 samples at one second), spikes and drops scored against it and confirmed over three consecutive samples, then correlated within five seconds into a named pattern with a diagnosis. It catches the change, not the time of day.
Example
CACHE_THRASHING warning redis-prod (ElastiCache) Cache thrashing detected with high miss rate and evictions keyspace_misses z=2.6 evicted_keys z=2.4
When you hit maxmemory, and what fixes it
A time-to-limit per instance from a rolling 6-hour regression, with a default alert when the limit is under two hours away. The cache size simulator samples the keyspace with SCAN and MEMORY USAGE, never KEYS, until the estimate is within 5%, projects growth from 30 days of key counts over a 30-day, 90-day or 6-month horizon, and recommends a node on ElastiCache, MemoryDB, Memorystore or Azure Cache for Redis that keeps the projected peak under 80% of usable memory.
Example
usedMemory on redis-prod: 1.9 GiB of 2.0 GiB, rising 38 MiB/h -> limit in 2h 40m simulator, 6-month horizon: 2.8 GiB -> cache.m7g.large (6.38 GiB, 75% usable)
Who is connected, across every cloud
CLIENT LIST snapshots every 60 seconds by client name and ACL user, with idle connections, buffer anomalies and spikes, rolled up for 90 days - and a fleet view that rolls every connection on every provider into one status with memory, ops/sec, clients and role per instance.
Example
checkout-api 42 connections (+18 vs 24h) idle > 5 min: 11 worker-eu 7 connections omem 12 MiB on 1 client
The provider decides what anyone can see
On a self-hosted server, BetterDB reads the slowlog, the client list, ACL LOG and the configuration. On a managed service, each of those is a command the provider may have switched off, and the choices differ from one service to the next. A blocked command disables only the feature that needs it; everything else keeps running.
Google Memorystore for Valkey is the clearest example. It publishes per-command statistics in Cloud Monitoring, which most providers do not. It also blocks SLOWLOG GET, CONFIG GET and all ACL commands, so no client-side tool, BetterDB included, can show slowlog patterns or an ACL audit trail there. Client history, capture sessions, anomaly detection, forecasting and the INFO-based metrics are all still available.
Where the service is private-only, the BetterDB agent runs inside your network as a container or npm package and connects outbound over WebSocket to BetterDB Cloud or to a self-hosted BetterDB, so the database never needs a public endpoint. Commands pass through a blocklist and a safe-mode allowlist on the agent.
Provider by provider
A monitoring tool that connects as a client can only read what the service lets a client run. This is what the documentation says for each.
AWS ElastiCache (Valkey and Redis)
Built-in monitoring
CloudWatch: host and engine metrics at one-minute grain. Full comparison on the CloudWatch page
What a client can read
INFO, SLOWLOG, CLIENT LIST and ACL LOG work; CONFIG, MONITOR and DEBUG are restricted
Network
VPC only, so the BetterDB agent runs on EC2 and dials out
Google Memorystore for Valkey
Built-in monitoring
Cloud Monitoring: server metrics every 60 seconds, plus call counts and time per command
What a client can read
INFO, CLIENT LIST, MONITOR and LATENCY work. SLOWLOG, CONFIG and every ACL command are blocked
Network
Private Service Connect only, so BetterDB or its agent runs inside your VPC
Azure Managed Redis
Built-in monitoring
Azure Monitor: server metrics at one-minute grain, connection events, big-key bucket counts in preview
What a client can read
It runs Redis 7.4, not Valkey, so there is no COMMANDLOG and no slot stats
Network
Public access or a private endpoint
DigitalOcean Managed Valkey
Built-in monitoring
Insights charts for up to 14 days, and a Prometheus metrics endpoint
What a client can read
ACL, CONFIG and MONITOR are restricted. SLOWLOG and CLIENT are not on the restricted list
Network
Public and VPC hostnames, with an IP allowlist
Aiven for Valkey
Built-in monitoring
Host metrics in the console. Valkey metrics come through the Prometheus or Datadog integrations
What a client can read
ACL, CONFIG and MONITOR are restricted. SLOWLOG and CLIENT are not on the restricted list
Network
Public access, VPC peering or PrivateLink
Upstash
Built-in monitoring
A console with request counts, bandwidth and storage
What a client can read
Direct connection over TLS; the BetterDB provider guide covers the setup
Network
Public endpoint with TLS required
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
Other providers
AWS has its own page, and the provider guides in the docs cover ElastiCache, MemoryDB, Redis Cloud and Upstash step by step.
Other comparisons: redis_exporter · Prometheus and Grafana · OTel Redis receiver · Datadog · APM tools · Percona PMM · Valkey Admin · Redis Insight · CloudWatch · RedisShake · ElastiCache migration
FAQ
Can BetterDB monitor Google Memorystore for Valkey?
Yes, with limits. Memorystore is reachable only through Private Service Connect, so BetterDB or its agent has to run inside your VPC. INFO, CLIENT LIST, MONITOR and LATENCY are available, so server metrics, client history, anomaly detection, forecasting and capture sessions all work. SLOWLOG, CONFIG and ACL commands are blocked by the service, so slowlog patterns and the ACL audit trail are not available there.
Can BetterDB monitor Azure Managed Redis?
Yes, as a Redis instance. Azure Managed Redis runs Redis 7.4, not Valkey, so the Valkey-only features - COMMANDLOG and CLUSTER SLOT-STATS - do not apply.
Does DigitalOcean expose Prometheus metrics for managed Valkey?
Yes. Each cluster has a Prometheus-format metrics endpoint with basic authentication, which carries far more series than the Insights charts. It reports server metrics; it does not include slowlog entries or client attribution.
Does the Aiven console show Valkey metrics?
The console shows host-level metrics: CPU, disk, load, memory and network. Valkey-specific metrics are available through Aiven integrations such as Prometheus and Datadog.
Can BetterDB tell me what node size I need?
Yes. The cache size simulator samples the keyspace with SCAN and MEMORY USAGE, never KEYS, projects growth from 30 days of key counts over a 30-day, 90-day or 6-month horizon, and recommends a node on ElastiCache, MemoryDB, Memorystore or Azure Cache for Redis that keeps the projected peak under 80% of usable memory. It needs the optional read-only key-sampling rules in the ACL.
Does my database need a public endpoint?
No. For private services, run the BetterDB agent next to the database. It connects outbound over WebSocket to BetterDB Cloud or to a self-hosted BetterDB, or you can self-host BetterDB inside the same network.
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.