Valkey vector search monitoring
Vector search turned Valkey into AI-serving infrastructure - and FT.SEARCH latency into user-facing latency. General database metrics don't see inside an index. This does.
What to monitor in a vector search workload
Query latency percentiles
FT.SEARCH p50/p95/p99 per index. Vector queries back user-facing AI features - tail latency here is tail latency in your product.
Query throughput
FT.SEARCH ops/sec per index, so a traffic shift to one index is visible before it becomes a capacity problem.
Index health
Document count, memory usage, and percent indexed - an index still backfilling serves incomplete results.
Indexing failures
Documents that failed to index are silently missing from every search until someone notices. This should be an alert, not a surprise.
Memory footprint
Vector indexes are memory-hungry (HNSW graphs live in RAM). Index growth competes with your keyspace for the same memory ceiling.
The instance underneath
A slow vector query is sometimes just a busy Valkey: CPU saturation, memory pressure, or a hot shard. Index metrics need instance context.
How BetterDB monitors it
Per-index health for valkey-search and RediSearch - document count, memory, indexing failures, percent indexed - alongside FT.SEARCH ops/sec and p50/p95/p99 latency per index, with SLA breach alerts (Pro, free in early access). All of it sits on the same timeline as instance metrics, is exported to Prometheus, and is queryable by AI assistants over MCP.
FAQ
What is vector search monitoring for Valkey?
Vector search monitoring is observability for similarity-search workloads running on valkey-search (or RediSearch): per-index health (document count, memory, indexing failures, percent indexed), FT.SEARCH query throughput and latency percentiles, and correlation with the underlying instance metrics - so slow or incomplete search results can be traced to their cause.
Does BetterDB support both valkey-search and RediSearch?
Yes. BetterDB detects the Search module and monitors per-index health and FT.SEARCH performance on both valkey-search and RediSearch deployments.
What are SLA breach alerts for inference latency?
You define a latency target per index (for example, p99 under 50ms), and BetterDB tracks p50/p95/p99 continuously and alerts when the target is breached. SLA features are Pro, currently free during early access.
Why is my FT.SEARCH slow?
Common causes, roughly in order: the instance itself is under pressure (CPU, memory, hot shard), the index is large or still backfilling, filters make the query more selective than the HNSW graph likes, or a traffic surge concentrated on one index. Effective debugging needs index metrics and instance metrics on the same timeline - which is what BetterDB provides, including via MCP so an AI assistant can run the investigation.
Can BetterDB also observe the AI application above the database?
Yes. BetterDB ingests OpenTelemetry traces from AI applications (LLM calls, cache lookups, memory recalls, retrieval spans) and correlates each span with live Valkey state - so you can tell whether a slow response came from the model, the cache, or the search index.
Running valkey-search? See inside your indexes
Ready to get started?
Start monitoring in minutes - no infrastructure to maintain. Team collaboration, agent-based monitoring for private databases, and more. Or self-host - open source core, zero lock-in.