6. Vector Store Design and Lifecycle
Choose storage, design chunk schemas, enforce metadata filters, and manage updates, deletes, and index migrations.
Vector Store Options
Options include dedicated vector databases, search platforms with vector support, relational database extensions, and managed provider-hosted stores. Compare metadata filters, hybrid search, update/delete semantics, backup/restore, consistency, scale, regional controls, cost, and operational effort.
Managed retrieval reduces infrastructure code but may constrain customization. Self-managed options give control but add monitoring, upgrades, backups, and incident response. Keep a recoverable source of truth so an index can be rebuilt.
System of record: source documents, ACLs, versions, jobs
Retrieval index: vectors, chunks/references, searchable metadata
Cache: short-lived derived results with scoped keys- Inspect the relevant pipeline stage instead of guessing.
- Preserve source provenance, versions, and access scope.
- Measure quality on representative queries.
What should guide vector-store selection?
Design a Chunk Schema
Each chunk needs a stable ID, source document ID, source version, text, embedding, source location, tenant/ACL metadata, and transformation versions. Stable IDs should account for document revisions and chunk boundary changes. Stale chunks must be removed or superseded on reindexing.
Metadata fields should reflect real filters and citation needs. Too few fields make authorization and provenance difficult; too many unconstrained fields add complexity.
{
"chunkId":"doc-18:v3:chunk-07",
"documentId":"doc-18",
"documentVersion":3,
"tenantId":"tenant-42",
"chunkerVersion":"semantic-v2",
"embeddingModel":"embedding-v1"
}- Inspect the relevant pipeline stage instead of guessing.
- Preserve source provenance, versions, and access scope.
- Measure quality on representative queries.
Why include document version on a chunk?
Metadata Filters and Tenant Isolation
Metadata filters constrain retrieval by tenant, group, publication status, language, date, and source type. Derive filters from authenticated server-side context; do not allow a model or untrusted query parameter to broaden access. Test how the chosen store applies filters, especially with approximate and hybrid search.
Use namespaces, partitions, row-level policies, separate indexes, or dedicated deployments according to threat model. A post-retrieval filter may be too late if unauthorized text has already reached intermediate systems.
function buildFilter(auth) {
if (!auth?.tenantId) throw new Error("Missing tenant");
return {tenantId:auth.tenantId,status:"published",deleted:false};
}- Inspect the relevant pipeline stage instead of guessing.
- Preserve source provenance, versions, and access scope.
- Measure quality on representative queries.
Where should tenant scope originate?
Upserts, Deletes, and Blue/Green Indexing
Index lifecycle errors create stale or unauthorized answers. A document update can leave old chunks behind; a deletion can leave vectors searchable; an embedding change can mix incompatible spaces. Use versioned chunk sets, transactional updates, or blue/green indexes.
For blue/green, build a new index, reconcile updates, run retrieval and security tests, switch traffic, retain the old index for rollback, then remove it when safe. Track status and counts throughout the process.
Build index B -> validate quality and ACLs -> switch traffic
-> retain index A for rollback -> delete A when safe- Inspect the relevant pipeline stage instead of guessing.
- Preserve source provenance, versions, and access scope.
- Measure quality on representative queries.
What is a benefit of blue/green indexing?