Latest updates, guides, and insights about Valkey monitoring and observability.
Redis re-added an OSI-approved license in May 2025, so why move off KeyDB to Valkey instead of Redis? Because 'open source again' is a license one company added and can route around next time, Valkey's structure has no mechanism to re-close, your RESP clients already work today, and the native-client story runs on AWS's and Google's payroll.
A team running BetterDB reported a Valkey Sentinel deployment that kept logging +tilt and flagging +sdown on healthy nodes, with raw IPs and plaintext as the only known workaround. This is the reproduction and the isolation matrix: a blocking getaddrinfo on Sentinel's single-threaded loop is the cause, TLS is not, and an FQDN in announce-ip stalls the peer Sentinels rather than the one that announced it. Verified on Valkey 8.1.8 and 9.0.6.
OpenAI runs Valkey as the cache behind a billion ChatGPT users. You won't build Habitat with two engineers and Codex - but if you run the same cache, here's how BetterDB makes operating it better: persisted slowlog and latency, hot-key and connection-storm detection, ACL auditing, and CVE scanning.
BetterDB monitor supports Valkey, Redis, KeyDB and - as of yesterday - Dragonfly. The same is most likely true for all RESP compatible databases. The credit goes completely to antirez, who designed a wire protocol fifteen years ago that turned out to be too simple and too good for anyone to replace.
The monitor now speaks OpenTelemetry in both directions: it re-emits its whole Prometheus surface and its events over OTLP, and its /v1/traces endpoint ingests OTLP spans from any instrumented service. That gives BetterDB four positions in your pipeline - feed your collector, be one, produce spans, or consume them and add the one thing a pure trace tool can't: the live database state behind the span. It fits wherever your stack has an OTLP-shaped socket open.
The most valuable work we did this week was also the least tweetable: patching CVEs nobody will ever see, halving our Docker image, and fixing build-pipeline plumbing. No AI, no new features - just the unglamorous work that separates a demo from something you can run at 3am. Here's what we did, and why we keep choosing it over the shiny thing.
We ship two caching libraries and people keep asking which one to use. The answer is a decision tree, not a product name. Here is the playbook: what to cache exactly, what to cache semantically, how to tune the threshold, and the numbers behind every claim.
Every layer of the AI stack grew its own observability, but the layers can't see each other. This is a story about merging the LLM trace and the cache decision into one waterfall with zero custom glue, because BetterDB and LangWatch both chose to speak OpenTelemetry.
A full month in review. BetterDB Monitor now runs fully air-gapped, speaks OpenTelemetry natively, grew its MCP surface, and picked up fifteen new anomaly detectors built straight from the Valkey issue tracker - plus cleaner migration off KeyDB and older Redis, and a month of caching and agent-memory SDK work.
The teams that most need deep database observability are often the ones that can't send a single packet to the outside world. BetterDB Monitor 0.28.0 runs fully air-gapped: signed licenses, local verification, zero phone-home. This post covers how it works and the honest trade-offs.
BetterDB vs @upstash/semantic-cache on four public datasets. Quality is at parity. The same embedding model produced different score distributions on each runtime, so the optimal threshold was different on each side, which is the whole argument for self-tuning. Latency is local Valkey vs a cloud REST API, so we report it as a deployment difference, not a library win. And BetterDB ships OpenTelemetry, Prometheus, and dollars-saved tracking in the MIT library, where Upstash ships none of it.
Over the past week we benchmarked our semantic cache against RedisVL and Upstash on four public datasets. Quality is at parity. Thresholds do not transfer between runtimes. Auto-tuning gains up to +2.8% F1 where the starting threshold was wrong. Latency is mostly about where you run the cache. And adversarial paraphrases beat every cosine cache.
BetterDB's Monitor-driven threshold autotuning on STSb and SICK: the cache loosened when too strict, tightened when too loose, and did nothing when it was already right. Up to +2.8% F1 on STSb and +2.1% F1 on SICK vs static thresholds, with zero degradation when the threshold was already optimal.
BetterDB vs RedisVL's SemanticCache on two public datasets, nine thresholds, and three configuration modes. Quality is at parity. First-query latency is at parity. On repeated queries BetterDB is 7x faster thanks to built-in embedding caching. Valkey and Redis 8 are indistinguishable. Full methodology and raw numbers included.
A cache optimizer on a 6-hour Vercel Cron that issues proposals and either auto-approves them or queues them for human review in BetterDB Monitor: three runs against chat.betterdb.com, 15 tool calls down to 8, and what the repetition between runs 1 and 2 revealed about a problem no amount of TTL tuning can fix.
I built a RAG chatbot over Valkey, Redis, and Dragonfly docs in a weekend, expecting to find that semantic caches silently corrupt answers when entity-swap queries collide. The data showed the opposite. Here is what we measured, what the architecture looks like, and where the real failure mode lives.
Why FT.INFO and INFO commandstats aren't enough for production vector workloads on Valkey or Redis - and how BetterDB's new Vector / AI tab closes the gap.
The quietest assumption in modern AI frameworks is that Redis means Redis 8 with modules. It doesn't, on any managed service you're likely to use. Here's why your agent cache breaks on deploy, and what to do about it.
BetterDB now forecasts ops/sec, CPU, memory, and fragmentation - so you can see capacity problems coming before they become incidents.
Stop switching tabs. BetterDB now includes an integrated CLI so you can investigate and act on what you see - without ever leaving the monitor.
BetterDB's migration tooling gives you a complete picture before you move a single key -- and confirms the picture after.
Why natural language access to Valkey observability data changes how incidents get investigated - and what it means for AI agents that use Valkey directly.
A walkthrough of the same MemoryDB incident debugged three ways - CloudWatch, BetterDB UI, and BetterDB MCP. Same data, very different outcomes.
Your AI app works great in dev. Then LLM costs spike, latency doubles, and your agent forgets mid-task. The problem is the layer between your app and your model.
Stop running ssh -L by hand every time you need to check something. Here's how to connect to remote Valkey and Redis instances via SSH tunnel without leaving your editor.
A practical guide to BetterDB's 99 Prometheus metrics - what they cover, how to configure scraping, and PromQL queries worth keeping around.
Why the database that was 'just a cache' might be the most important piece of your AI infrastructure
Most monitoring tools claim low overhead but never show their work. Here's the interleaved benchmark methodology we use to measure BetterDB's monitoring overhead on Valkey and Redis.
BetterDB 0.3.0 introduces native webhook notifications-real-time alerts for your Valkey or Redis databases without requiring Prometheus or Alertmanager.
Browse keys, edit values, and run commands against Valkey and Redis without leaving your editor. MIT-licensed and open source.