BetterDB vs Datadog
Run both, and Datadog pages you while BetterDB shows you why. BetterDB watches only Valkey and Redis, and keeps what Datadog's check drops at collection time: the slow commands with the client that sent them, the oversized requests, the denied ACL calls and who was connected. On top of that it runs detectors built around how Valkey fails, forecasts time-to-limit for memory, and checks your server version against known CVEs. It works the same on Redis 7; only COMMANDLOG and slot stats need Valkey 8.
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 Datadog alone when…
- INFO-level metrics per node are all you look at when Redis misbehaves
- You need traces through Redis client calls, host metrics and logs in one place
- Your organization has standardized on one observability vendor, and adding a tool is the harder problem
Run both when…
- Datadog pages you, and you want the database-level evidence already stored when you open the laptop
- You run Valkey 8.1+ and want its COMMANDLOG (large-request and large-reply logs Redis does not have) and per-slot stats, which the Datadog check does not collect
- You want BetterDB metrics and events on your Datadog dashboards - it exports OTLP and Prometheus
Use BetterDB instead when…
- Valkey or Redis is the only thing you need to monitor, or the thing that keeps breaking
- Monitoring data has to stay in your network - BetterDB self-hosts, including air-gapped
- You need a persistent ACL audit trail and slowlog history, not rolling aggregates
- You want split brain, replication divergence and failover churn detected, not just a threshold on used memory
Side by side
| Capability | BetterDB | Datadog |
|---|---|---|
| Scope | Valkey and Redis only | Hosts, containers, applications, logs and traces - over 1,000 integrations |
| Valkey support | Yes. COMMANDLOG and slot stats switch on where the version has them | No dedicated integration. The Redis check reads Valkey over the shared protocol and collects none of the Valkey-only data |
| Server metrics from INFO | Yes, stored, plus 110+ Prometheus metrics | Yes - 271 metrics, kept for 15 months |
| Slowlog | The entry itself: arguments, duration, timestamp, client address and name, grouped by pattern, key prefix and client | A duration histogram tagged with the command name. Arguments, client and entry ID are discarded |
| COMMANDLOG (Valkey 8.1+) | Collected and stored; large requests and replies grouped by pattern | Not collected |
| Cluster | One seed is enough: auto-registration (opt-in) adds every node and keeps the list in sync. Topology graph and a heatmap of all 16,384 slots | CLUSTER INFO health only; one check instance per node |
| ACL denials | The denials themselves, persisted by reason and by user | Denied counters by reason, from INFO |
| Client visibility | Every client, on by default: CLIENT LIST snapshots every 60 seconds by name and ACL user, rolled up for 90 days | A connection count per client name, opt-in |
| Key-level data | Nothing to configure: a 5-minute sample ranks hot keys by access frequency with rank movement, and sizes the largest keys | Length of the keys or patterns you list in the config |
| Anomaly detection | Built for Valkey: more than 20 detectors scored against a rolling five-minute baseline and correlated into named patterns with a diagnosis - split brain, replication divergence, retry amplification | Watchdog, which analyzes infrastructure metrics including Redis |
| Forecasting | The same idea with no monitor to build: time-to-limit for memory, CPU, ops/sec and fragmentation per instance, plus a cache size simulator that recommends a node size | Forecast monitors on any metric |
| Security checks | Server and module versions matched against five CVE feeds every 6 hours; config drift across replicas and shards; config hazard checks | Not part of the Redis check |
| Traffic capture | Opt-in MONITOR captures: on demand, scheduled, or armed for the next recurrence of an anomaly. 30 seconds by default, capped and health-gated | Not available |
| Application context | Only OTLP traces from your own application, correlated with live key and TTL state. No host or log monitoring | APM traces through Redis client libraries, plus host metrics and Redis logs |
| Where the data lives | In your network when self-hosted, including air-gapped with the CVE feed turned off; or BetterDB Cloud | Datadog-operated SaaS sites |
Scope
BetterDB
Valkey and Redis only
Datadog
Hosts, containers, applications, logs and traces - over 1,000 integrations
Valkey support
BetterDB
Yes. COMMANDLOG and slot stats switch on where the version has them
Datadog
No dedicated integration. The Redis check reads Valkey over the shared protocol and collects none of the Valkey-only data
Server metrics from INFO
BetterDB
Yes, stored, plus 110+ Prometheus metrics
Datadog
Yes - 271 metrics, kept for 15 months
Slowlog
BetterDB
The entry itself: arguments, duration, timestamp, client address and name, grouped by pattern, key prefix and client
Datadog
A duration histogram tagged with the command name. Arguments, client and entry ID are discarded
COMMANDLOG (Valkey 8.1+)
BetterDB
Collected and stored; large requests and replies grouped by pattern
Datadog
Not collected
Cluster
BetterDB
One seed is enough: auto-registration (opt-in) adds every node and keeps the list in sync. Topology graph and a heatmap of all 16,384 slots
Datadog
CLUSTER INFO health only; one check instance per node
ACL denials
BetterDB
The denials themselves, persisted by reason and by user
Datadog
Denied counters by reason, from INFO
Client visibility
BetterDB
Every client, on by default: CLIENT LIST snapshots every 60 seconds by name and ACL user, rolled up for 90 days
Datadog
A connection count per client name, opt-in
Key-level data
BetterDB
Nothing to configure: a 5-minute sample ranks hot keys by access frequency with rank movement, and sizes the largest keys
Datadog
Length of the keys or patterns you list in the config
Anomaly detection
BetterDB
Built for Valkey: more than 20 detectors scored against a rolling five-minute baseline and correlated into named patterns with a diagnosis - split brain, replication divergence, retry amplification
Datadog
Watchdog, which analyzes infrastructure metrics including Redis
Forecasting
BetterDB
The same idea with no monitor to build: time-to-limit for memory, CPU, ops/sec and fragmentation per instance, plus a cache size simulator that recommends a node size
Datadog
Forecast monitors on any metric
Security checks
BetterDB
Server and module versions matched against five CVE feeds every 6 hours; config drift across replicas and shards; config hazard checks
Datadog
Not part of the Redis check
Traffic capture
BetterDB
Opt-in MONITOR captures: on demand, scheduled, or armed for the next recurrence of an anomaly. 30 seconds by default, capped and health-gated
Datadog
Not available
Application context
BetterDB
Only OTLP traces from your own application, correlated with live key and TTL state. No host or log monitoring
Datadog
APM traces through Redis client libraries, plus host metrics and Redis logs
Where the data lives
BetterDB
In your network when self-hosted, including air-gapped with the CVE feed turned off; or BetterDB Cloud
Datadog
Datadog-operated SaaS sites
Checked against the Datadog Agent Redis check v8.11.0 and BetterDB 0.54.0, November 2026. Spot something out of date? Tell us and we will fix it.
Sources: Datadog Redis check source · Datadog Redis integration docs · Database Monitoring docs
What the Datadog check leaves out
Three things that need commands the Redis check never runs, or state it never keeps.
The slow command and who sent it
Datadog keeps a duration per command name. BetterDB keeps the entry, with numeric IDs, UUIDs and long tokens in the key replaced by a wildcard so thousands of entries collapse into patterns you can chart, alert on and search for any time range.
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
A diagnosis, not a Watchdog line
Watchdog tells you a Redis metric moved. BetterDB correlates the anomalies that moved together, within five seconds, into a named pattern with the probable cause and what to check next. Baselines are rolling five-minute windows per metric, confirmed over three consecutive samples, so a deploy raises one event, not a page storm.
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
Capture the next time it happens
Arm a MONITOR capture on an anomaly and BetterDB records the traffic when it recurs, then diffs it against history: new command shapes, hot-key changes, slowlog regressions and ACL deltas. Captures are opt-in, 30 seconds by default, capped at 50 MB, refused above 85% memory or during a failover, and can redact values.
Example
trigger: CONNECTION_LEAK on cache-eu-1 -> capture 30 s, values redacted cross-reference vs 24h: new command shapes, hot-key delta, slowlog regressions, ACL deltas
What happens to a slow command
Datadog's check runs SLOWLOG GET on every collection and turns each new entry into one data point: a duration, tagged with the command name.
redis.slowlog.micros{command:hgetall}
avg / median / 95percentile / max / countThat tells you HGETALL was slow. It cannot tell you which key or which client, because the arguments, the client address and the entry itself are dropped when the metric is built.
BetterDB polls SLOWLOG GET every 30 seconds and stores each entry: the command with its arguments, the duration, the timestamp, and the client address and name. The pattern metrics it exports are a summary of them, for dashboards and alerts:
betterdb_slowlog_pattern_count{pattern="HGETALL session:*"} 24
betterdb_slowlog_pattern_avg_duration_us{pattern="HGETALL session:*"} 1250000
betterdb_slowlog_pattern_percentage{pattern="HGETALL session:*"} 18.75One limit to know: a burst that overflows the slowlog buffer between two polls is lost to any tool.
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
Send BetterDB metrics to Datadog
BetterDB mirrors its metrics and events over OTLP and exposes the metrics on a Prometheus endpoint, so they can sit next to everything else you already send to Datadog. The same series drive our public Grafana demo.
Other comparisons: redis_exporter · Prometheus and Grafana · OTel Redis receiver · APM tools · Percona PMM · Valkey Admin · Redis Insight · CloudWatch · cloud monitoring · RedisShake · ElastiCache migration
FAQ
Does Datadog support Valkey?
There is no Valkey integration for the Datadog Agent as of November 2026. The Redis check uses commands that Valkey also answers, so it can collect INFO metrics from a Valkey server, but its documentation does not mention Valkey and it collects none of the Valkey-only surfaces such as COMMANDLOG or CLUSTER SLOT-STATS. Datadog does have a cloud integration for Google Cloud Memorystore for Valkey, which reports the provider metrics.
Does BetterDB work on Redis, or only Valkey?
Both. On Redis and on Valkey before 8.1 it reads SLOWLOG instead of COMMANDLOG and has no per-slot stats; everything else on this page applies, including on ElastiCache for Redis through the agent.
Does Datadog show the Redis slowlog?
As a metric, not as a log. The check reads SLOWLOG GET and emits redis.slowlog.micros, a duration histogram tagged with the command name. The arguments, client address and entry ID are not kept, so you can see that a command type was slow but not which call it was.
Does Datadog Database Monitoring cover Redis or Valkey?
No. Database Monitoring covers Postgres, MySQL, MariaDB, Oracle, SQL Server, MongoDB, DocumentDB and ClickHouse. For Redis and Valkey, Datadog offers the Agent check, APM traces through client libraries, and log collection.
What does BetterDB detect that a Datadog monitor would miss?
Conditions that need more than one metric or a state change: two primaries claiming the same slot range, a replica promoted while lagging, repeated re-elections, a replica that stopped applying its backlog, Sentinel endpoints drifting from the real pods. Each has its own detector, built around a reported Valkey issue, and the anomalies are correlated into one diagnosis with recommendations.
Can I run BetterDB and Datadog together?
Yes. Keep Datadog for alert routing, APM and the rest of your stack, and use BetterDB for the database-level history and the Valkey-specific detectors. BetterDB exports its metrics over OTLP or Prometheus so they appear in Datadog; the vitals export profile, a fixed set of 33 core series per standalone instance, keeps the series count small.
Can BetterDB replace Datadog?
Only for Valkey and Redis. BetterDB does not monitor hosts, applications or logs, and it has no APM. If the cache is the one thing you need deep visibility into, BetterDB alone can be enough; if you need a single pane for the whole stack, keep Datadog and add BetterDB.
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.