Vector index configuration is one of the most consequential and least revisited decisions in semantic search systems. The post explains why creating a vector index is an architectural commitment — locking in memory model, compression scheme, and query syntax — and why changing it later is expensive. It covers the three-way tension between recall, latency, and cost, then details three Couchbase index types (Hyperscale, Composite, and FTS Search Vector Index), each suited to different scale and filter patterns. Common failure modes are described: the simplicity trap (picking FTS and hitting memory limits at 130M+ vectors), the scale-fixation trap (choosing Hyperscale when filter-first would be faster), and codebook drift (IVF centroids becoming unrepresentative as data evolves, silently degrading recall). A decision framework based on keyword needs, scale thresholds, filter selectivity, and growth projections is outlined, along with a Couchbase Vector Index Advisor tool that guides teams through the diagnostic questions before writing a CREATE statement.
Table of contents
Creating an index is a commitment, not a settingThe trade-off you cannot configure your way out ofThree indexes, three different betsWhere the wrong choice turns into an incidentThe right answer starts with the right questionsAn advisor built around asking the right questionsThe pointQuestions this post answers
What is codebook drift in IVF vector indexes and how do I fix it?
Codebook drift occurs when an IVF-based vector index trains its cluster centroids on a data sample taken at build time, and new data flowing in diverges from that original sample. The centroids stop being representative, and recall slowly decays with no error or alert — results just get gradually worse. The fix is a periodic index rebuild, which is straightforward once you know the hazard exists. Teams running long-lived vector indexes track recall degradation patterns like this on daily.dev.
What are the memory requirements for a Composite Vector Index with 100M vectors at 1536 dimensions using SQ8 quantization?
At 100M vectors with 1536 dimensions, the quantized vector payload alone using SQ8 (one byte per dimension) is roughly 144 GB before accounting for centroids, graph structure, and scalar columns. The Index Service must keep the working set resident in its memory quota; if pushed past that quota, it stops serving scans until memory is freed. Developers sizing vector infrastructure for production workloads find real benchmark comparisons on daily.dev.
When should I use an IVF Composite vector index versus a Hyperscale vector index?
Use a Composite index when queries carry narrow scalar filters that keep only a thin slice of the corpus eligible — the filter-first execution means expensive nearest-neighbor work runs over a small subset rather than the full dataset, making it the right choice for multi-tenant applications and strongly partitioned catalogs. Use a Hyperscale index when filters are broad or absent, or when the dataset exceeds 100M vectors and memory constraints rule out keeping vectors resident in RAM. Engineers deciding between vector index architectures for their stack follow these trade-offs on daily.dev.