Stop counting indexes

Benchmarking Valkey Search showed that the number of indexes alone is not the main determinant of write performance: indexes on unrelated key prefixes impose no measurable cost because prefix matching uses a trie, while multiple indexes matching the same keys create separate indexing jobs and reduce write capacity, though with diminishing marginal impact as work is distributed across writer threads. In tests on an r7i.4xlarge server, adding a first standard TAG and NUMERIC index reduced sustainable writes from 80,000 to about 33,636 per second, while four matching indexes sustained about 16,818 writes per second but processed over 67,000 indexing jobs per second. Vector indexing was far more costly, as adding a 1024-dimensional HNSW field dropped throughput from 32,000 to 2,828 writes per second and produced sharp latency cliffs once capacity was exceeded. However, adding a lightweight lexical exact-match index alongside a vector-heavy semantic index caused only about a 3% additional impact because writes wait primarily for the slower vector operation. The findings suggest capacity planning should focus on the fields in indexes that match hot keys, especially vector fields, rather than on overall index count, and emphasize measuring queue depth and latency at progressively varied load levels to identify sustainable throughput before saturation.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.