Vector Database Operations: Index Types and Zero-Downtime Migration

Two decisions dominate the operational life of a vector database: which index structure you build, and how you move the data when the first decision — or the vendor behind it — stops fitting. Both are reversible, but only if you engineer them that way from the start. This guide covers the index families worth knowing and a migration method that keeps retrieval live throughout.

1. By the numbers

2. The real decision: an index is an operational commitment

Index selection gets presented as a benchmark contest — recall on one axis, queries per second on the other. That framing hides what a platform team actually signs up for. An index structure determines how expensive inserts and deletes are, whether the index degrades as data drifts, how much RAM the working set demands, and how long a rebuild takes when you change embedding models. Those are the costs you live with monthly; raw query speed is tunable after the fact.

The published research is unambiguous that this is a trade-off space, not a leaderboard. The Faiss paper — written by the Meta team that maintains the most widely studied open-source similarity-search toolkit — frames the entire library around "the trade-off space of vector search," describing Faiss as "a toolkit of indexing methods and related primitives used to search, cluster, compress and transform vectors."^[4] Search, cluster, compress, transform: four verbs, and only one of them is the query path.

3. Flat: the baseline you should keep around

A flat index is exhaustive search: compute the distance from the query vector to every vector in the collection and return the closest. It is exact by construction, needs no training, and has no parameters to mistune. Its cost scales linearly with corpus size, which eventually prices it out of the serving path — but never out of the engineering workflow. Every approximate index you deploy should be evaluated against flat-search ground truth on a sample of real queries, because recall is only measurable relative to the exact answer. Teams that skip this step end up tuning approximate indexes against each other, which measures agreement, not correctness.

4. IVF: cheap memory, but the clusters go stale

Inverted-file (IVF) indexes partition the vector space into clusters at build time, then search only the partitions nearest the query. The number of partitions probed is the operator's dial: probe more, recall rises and latency rises with it. The structure is memory-frugal relative to graph indexes, which is why it persists in cost-sensitive deployments — pgvector's IVFFlat variant remains a supported path on managed Postgres, and the pgvector 0.5.0 release AWS shipped to Aurora added "parallelization of ivfflat index builds" to make its main weakness, rebuild time, cheaper.^[5]

That weakness matters because IVF's partitions are trained on the data present at build time. As your corpus grows and drifts — new document types, a new embedding model, a new language — the centroids describe a distribution that no longer exists, and recall decays quietly. IVF is a reasonable choice for corpora that are large, mostly static, and rebuilt on a schedule. It is a poor choice for feeds with continuous ingestion unless you automate periodic retraining and treat recall as a monitored production metric.

5. HNSW: the default for dynamic, latency-sensitive workloads

Hierarchical Navigable Small World graphs are the index behind most low-latency vector serving today. The 2016 paper by Malkov and Yashunin describes a structure that "incrementally builds a multi-layer structure consisting from hierarchical set of proximity graphs (layers) for nested subsets of the stored elements."^[1] Search starts in a sparse top layer, descends through progressively denser layers, and the authors show this scale separation "allows a logarithmic complexity scaling" — the property that lets query latency stay nearly flat while the corpus grows by orders of magnitude.^[1]

The word to notice in that abstract is "incrementally." HNSW inserts elements one at a time into a live graph, which is what makes it fit continuously changing corpora without scheduled rebuilds. The managed-database ecosystem confirmed this is the property enterprises buy: when AWS brought pgvector 0.5.0 with HNSW to Aurora PostgreSQL in October 2023, the announcement led with exactly this — the new index type "supports concurrent inserts, and updating/deleting vectors from the index."^[5] The costs are the graph itself, which stores multiple links per element and makes HNSW the most memory-hungry family per vector, and build time, which is why AWS's own knowledge-base guidance recommends setting `ef_construction` to 256 on pgvector 0.6.0 and higher to exploit parallel index building.^[6]

6. Quantization: when the corpus outgrows RAM

Past a certain corpus size, the binding constraint stops being latency and becomes memory. Quantization techniques compress vectors into compact codes and search the compressed representation — product quantization in the Faiss lineage, whose toolkit exists precisely to "search, cluster, compress and transform vectors" at scale,^[4] and tree-quantization hybrids like Google's ScaNN. Google's own documentation describes ScaNN as "a Google-made, tree-based quantization index for approximate nearest neighbor search" and claims it "provides lower index building time and smaller memory footprint as compared to HNSW" along with faster queries per second "based on the workload."^[3] The same algorithm underpins Vertex AI Vector Search, Google's dedicated managed offering.^[7]

The trade is that compression is lossy: distances computed on codes are approximations of approximations, so quantized indexes typically pair with a reranking pass over exact vectors for the short list. Treat quantization as an economics decision. If a graph index over full-precision vectors fits your memory budget at projected corpus size, take the simpler system. If it does not — or the hosting bill says it soon won't — quantization is how billion-scale corpora become operable on hardware you can actually buy, which is the regime Faiss was built for.^[2]

7. The Postgres consolidation is real — and it changes the migration question

Every hyperscaler now ships vector search inside managed PostgreSQL. AWS made pgvector available on Aurora PostgreSQL in July 2023, across versions 15.3, 14.8, 13.11, and 12.15 and higher, including GovCloud regions.^[8] Microsoft documents the same extension on Azure Database for PostgreSQL, noting that "the pgvector extension adds an open-source vector similarity search to PostgreSQL" with native operators for Euclidean, cosine, and inner-product distance.^[9] Google's AlloyDB goes furthest, exposing ScaNN alongside the standard pgvector index types.^[3]

For a platform lead, this shifts the default question from "which vector database do we buy?" to "does our vector workload justify a separate database at all?" A dedicated engine still earns its place at large scale or under specialized filtering and hybrid-search demands. But if your relational source of truth already lives in managed Postgres, co-locating embeddings removes an entire synchronization pipeline — and the operators, index types, and distance functions are documented, portable SQL rather than a proprietary API.^[9] That portability is precisely what the second half of this guide is about.

8. Zero-downtime migration: a method, not a product

Teams migrate vector databases for familiar reasons: cost at scale, vendor concentration risk, a consolidation push toward Postgres, or a capability gap. The market's dedicated engines — Pinecone, Weaviate, Qdrant, Milvus, and others — each have their own export surfaces and index internals, and those specifics change fast enough that you should design the migration to not depend on them. The durable method is the same one used for any stateful system: establish a source of truth outside the database, backfill the target, run both in parallel, prove parity, then cut over. Vector search adds one twist — approximate indexes on two systems will not return identical results, so "parity" needs a statistical definition, not an equality check.

Phase 1 — Inventory and export

Start with an audit, not a script: corpus size, vector dimensionality, distance metric, metadata fields used for filtering, and the query patterns that actually hit the system. Dimensionality and metric are the two silent breakers — the target schema must match the embedding model exactly, the way AWS's Aurora knowledge-base guidance pins column definitions per model, such as `vector(1024)` for Amazon Titan v2 or `vector(1536)` for Titan v1.2.^[6] Then export in batches through whatever official surface the source system provides, capturing three things per record: the vector, its stable ID, and its metadata. Land the export in neutral object storage in a boring format. If you follow the derived-data posture above, this export is a safety net rather than the primary path — re-embedding from source documents sidesteps every export-format quirk.

Phase 2 — Backfill and shadow reads

Load the target system in bulk, then build the index — order matters, because most engines build indexes dramatically faster over resident data than by incremental insertion. Reproduce the distance metric first and tune index parameters second; a cosine-tuned workload queried through a Euclidean operator produces plausible-looking wrong answers. Once the target is loaded, run shadow reads: mirror a sample of production queries to both systems and compare the result sets. The metric that matters is overlap@k against the source system and, ideally, against flat-search ground truth — measured across your real query distribution, not a synthetic benchmark. Set an explicit acceptance threshold with the retrieval owners before cutover week, and pressure-test relevance the same way you would any retrieval change (see /guides/enterprise-retrieval-tuning).

Phase 3 — Dual-write, cutover, rollback

With backfill validated, open dual-writes: every upsert and delete now goes to both systems, either at the application layer or through the event stream that feeds your ingestion pipeline. Dual-writing turns the migration from a race against data freshness into a stable steady state you can hold for weeks. Cut reads over gradually behind a routing flag — one internal tenant, then a traffic percentage, then everyone — while watching error rates, tail latency, and retrieval-quality signals. Keep dual-writes running after full read cutover; that is your rollback: flip the read flag back and the source system is still current. Decommission the source only after a full business cycle of clean operation, and remember the access-control model moves with the data — collection-level permissions and tenant isolation need re-verification on the target (see /guides/securing-enterprise-rag).

9. Honest objections

First: most teams contemplating a migration should negotiate instead. A migration consumes a quarter of platform-engineering attention, and the dual-write phase means running two systems — paying for both — for weeks. If the driver is purely price, a committed-use discount is cheaper than an engineering project. The migration case is strongest when the driver is structural: a capability gap, a consolidation mandate, or concentration risk your architecture review flagged.

Second: the re-embedding posture this guide recommends is not free. At large corpus sizes, re-running an embedding model over every document is a real compute bill, and if the model is a paid API, a real invoice. The counterargument is that you will pay it eventually anyway — embedding models improve, and a corpus embedded on a retired model is itself a migration waiting to happen. Keeping the re-embed pipeline warm is what makes both events routine.

Third: the Postgres-consolidation argument has limits. pgvector inherits Postgres's operational model — which is a feature until your vector workload's memory profile and your transactional workload's start competing on the same instances. Dedicated engines exist because at some scale, isolation wins. The honest read is that consolidation is the right default and separation is the earned exception, justified by measured contention rather than by a vendor's scale narrative.

10. The read

Choose the index by update pattern and memory budget: flat for small or correctness-critical sets and for ground truth, IVF for large mostly-static corpora with scheduled rebuilds, HNSW for dynamic low-latency serving, quantization when RAM economics demand it.^[1] Choose the platform by gravity: co-locate with managed Postgres unless measured scale or isolation needs justify a dedicated engine.^[8] And buy your future exit at design time — source-of-truth outside the database, embedding versions pinned, ingestion behind an event stream — because a zero-downtime migration is cheap for teams that prepared and a rewrite for teams that did not.