The optional copy is not the search index itself
A museum collection index stores text embeddings for object descriptions, rights notes, and conservation summaries. Storage costs grow, and a developer notices the Azure AI Search vector field property stored. The name is easy to misread: setting stored to false removes an optional retrievable source-vector copy, not the vector representation needed for similarity search. Azure documentation explains the distinct copies used for query execution, raw-vector retrieval, and—in some compression configurations—rescoring. Before changing an index design, determine whether your application ever returns vectors, incrementally updates documents, or performs reranking that depends on preserved originals. Storage optimization is not automatically safe for all those workflows.
Separate stored from retrievable
For vector fields, stored controls whether the retrievable source representation is kept, while retrievable determines whether that content may be returned in results. Azure documentation says the default for vector fields is stored true and retrievable false. If stored is false, retrievable must also be false, and later switching retrievable to true is not an option for that field. This differs from a conventional searchable text field, where display and index configuration have other semantics. A public museum catalog generally does not need to display raw embedding arrays, but a debugging tool or a separate downstream consumer may need them. Inventory consumers instead of assuming that “not shown in search results” means “never required.”
Treat stored:false as an index-creation decision
Microsoft describes stored:false as an immutable choice made when creating an index’s vector field. You cannot simply toggle an established field to false and assume Azure will shrink it in place, or turn the copy back on after discovering an update dependency. Plan a new index or appropriate new field with the desired configuration, backfill from authoritative source data, and evaluate it before switching traffic. Preserve the existing index for rollback during migration. A test index is particularly important when collection records are updated throughout the day and the app uses partial indexing actions rather than complete document replacements. Document who approved the decision and which source embeddings can be regenerated.
The hidden failure in partial document updates
Azure warns that with stored:false, a partial merge or mergeOrUpload action that omits the vector field can cause that existing vector data to be lost without an explicit warning. This is the central operational risk. A catalog editor might update only a public caption while leaving the embedding field out of the request; the text appears correct, but subsequent vector searches no longer find the item. Do not infer that a successful index write means vector integrity was preserved. The safer alternatives are keeping stored true for workloads that regularly use partial updates, or always including the full required vector when updating a document under the optimized schema.
Design a complete update payload
A robust update job starts with the authoritative record ID, its current text revision, the embedding model and dimensions, and a reproducible vector generation or retrieval path. If the vector is required on every update, the job must supply it together with the edited fields instead of relying on a hidden retained copy. Reject records whose embedding does not match the index profile, whose source revision changed during processing, or whose rights status is unresolved. Keep document keys and source IDs stable. This approach increases application work, but it prevents a benign metadata edit from silently degrading retrieval recall. Decide whether the storage benefit justifies that maintenance burden.
Do not conflate compression storage with stored
Azure may also keep full-precision originals to support rescoring when using compressed vector indexes. The documentation describes rescoring storage options separately from the source-vector stored property. A team cannot assume that setting stored:false removes every nonessential vector copy or that a compression change is equivalent to disabling raw-vector retrieval. Map exactly which index instance performs search, which one supports updates, and which one supports rescoring. Evaluate memory and disk usage separately, because stored is a disk-layout decision and does not by itself shrink the search graph or guarantee lower query latency. Treat space-saving figures in provider documentation as workload-dependent possibilities rather than measured savings for your museum.
Compare three caption-update outcomes
A useful comparison shows a conventional index retaining the vector after a caption-only update, a stored:false index losing the vector when the update omits it, and a stored:false index receiving the complete vector together with the caption. The second state is a warning, not an intended operating mode. Diagrams should make the missing vector visible rather than simply drawing three identical document cards. These examples are conceptual, not actual measured Azure search results. The important test is whether an unchanged query still retrieves the revised record and whether an exact source ID inspection confirms the vector was indexed as planned.
Validate recall and records after migration
Create an evaluation set of known catalog queries that should retrieve specific items, including unusual accession codes and recently edited descriptions. Run the same set against the old and new index using consistent filters, vector dimensions, and ranking configuration. Record missing target IDs, unexpected distribution changes, indexing errors, and results after a metadata-only update. A successful index creation or a lower storage bill does not certify the search experience. Compare results against curator-approved source records and retain a rollback target if coverage falls. A small set of verified difficult records is more informative than an unqualified claim that “queries still work.”
Choose safety over an attractive storage metric
If the museum’s system frequently performs partial updates and cannot reliably supply the complete vector, keeping stored true may be the responsible decision. If full-vector updates are guaranteed and downstream consumers do not need raw embeddings, a carefully tested stored:false design can reduce optional storage. Record the irreversible schema choice, dependent services, embedding regeneration procedure, and acceptance tests in a versioned architecture note. For collection records that carry access restrictions, remember that field storage choices do not constitute permission enforcement. Authorization and editorial review still govern what a visitor may retrieve or publish.
How We Research
Our research consulted these named official documents: Microsoft Learn: Eliminate optional vector instances from storage; Microsoft Learn: Create a vector index; Microsoft Learn: Indexing documents in Azure AI Search. We checked tool behavior, version-specific options, and stated limitations against an illustrative museum scenario. The examples are suggested implementation and editorial review procedures, not production tests. We did not call the services with live patron records, benchmark latency or accuracy, measure storage savings, or obtain third-party consent. All images are original explanatory drawings rather than screenshots or claimed measured results. Verify provider documentation, service availability, access policies and current organization rules before adoption; keep final publication approval with authorized staff.
Frequently Asked Questions
No. The vector representation required for similarity search remains; this setting omits an optional retrievable source copy.
Do not assume so. Microsoft describes the setting as immutable for vector fields and applied when creating the field/index.
If stored is false and the update omits the vector, Azure may lose that vector without warning. Include the full vector or keep stored true.
No. Retrievable controls whether a field can appear in query results; stored controls retaining an optional vector copy used for that purpose and some updates.
Not necessarily. Compression rescoring storage is controlled separately; review the complete vector storage configuration.