Vector Database: Which Azure AI Search Stats and Roles Matter?

Quick Answer: For a 100,000-document vector database, check Azure AI Search's service quota with GET Service Statistics and each index's storageSize and vectorIndexSize with GET Index Statistics ¹. Size changes with data, algorithms, updates and partitions ². Give a querying application Search Index Data Reader, scoped to one index where appropriate ³.

Summary in a mind map

Vector Database: Which Azure AI Search Stats and Roles Matter?
├─ Retrieval purpose
│   ├─ RAG pairs a model with separate retrieval
│   ├─ Search engine or vector database may supply context
│   └─ Test representative documents and questions
├─ Capacity evidence
│   ├─ Service Statistics shows total quota and use
│   ├─ Index Statistics shows disk and vector size
│   └─ Record configuration with each measurement
├─ Growth factors
│   ├─ Raw data and algorithm overhead matter
│   ├─ Updates and deletes change size
│   └─ Partitions change available quotas
└─ Query access
    ├─ Search Index Data Reader permits queries
    ├─ Scope the grant to one index if appropriate
    └─ Test intended access and unintended refusal

What vector retrieval adds

A vector database is one way to retrieve context for a model's answer. NIST defines retrieval-augmented generation, or RAG, as a model paired with a separate retrieval system or knowledge base that supplies relevant information in context ⁴. The model is therefore not where all the knowledge resides. A business can update its document collection without describing that operation as retraining the model. The retrieval step has its own quality, capacity and access questions.

Eurostat describes retrieval as possible through either a search engine or a vector database ⁵. The choice should follow the questions the company must answer, the documents it can lawfully use, and the quality of the retrieved passages. A 100,000-document count is a workload description, not proof that one technology is required. Start with a representative sample of documents and questions before estimating infrastructure for the full collection.

The European Commission's GraphRAG report gives a concrete research example: it describes vector-based retrieval over the LOV RDF graph and then an answer formulated from returned documents ⁶. That example illustrates the two-step shape. It is not a capacity benchmark for an accounting firm. The firm's own files, update rate, vector fields and permission model must be measured in its own proposed service.

Check service-wide vector quota

Azure AI Search exposes overall quota and usage through GET Service Statistics ¹. This is the first measurement for a service that may hold more than one index. A new document project does not receive the whole service's capacity if existing indexes already consume some of it. The project record should hold the service, inspection date, current usage and available quota before a 100,000-document import.

A useful baseline has three parts: what the service currently uses, what a test index adds, and what margin remains after the sample. Keep the measured figures separate from estimates. If the service is shared with another application, a service-wide check prevents the project team from presenting its own index as the sole consumer. The documented statistics are a snapshot, so the same check should be repeated after a material configuration change ¹.

A service statistic cannot explain which field within one index caused growth. It tells the team whether it has room at the service level. For a project decision, pair it with per-index statistics rather than replacing one with the other. This distinction also lets a reviewer ask the right owner for a remedy: index design belongs with the project, while shared service capacity may belong with a platform team.

Check one index's disk and memory

GET Index Statistics exposes an individual index's usage, including storageSize and vectorIndexSize ¹. The team should record both values after loading a representative sample. The first value is a storage measurement; the second specifically reports vector index size. Microsoft reports usage and quota in bytes ¹. They answer different questions, so a planning sheet should not label either one simply “database size” without its unit and source.

For an accounting firm's records room, the sample should reflect actual file types, document lengths and update patterns. Ten thousand convenient short documents are a poor stand-in if the remaining ninety thousand contain longer records. The firm can choose a sample from several document groups and preserve the group sizes alongside the statistics. The reported values, in bytes, then describe the tested index, not an imagined average document.

The index measurements should be taken again after updates and deletions in the sample. A one-time initial load tells the team too little about an index that changes every week. The comparison should use the same index and record load phase, update phase and measurement time. That produces a traceable capacity estimate without claiming the sample predicts every future document.

Why capacity changes after loading

Microsoft says vector index size depends on raw data size, algorithm overhead, and deleted or updated documents ². HNSW indexes require memory residency for their vector structures, whereas exhaustive KNN indexes have no memory residency requirement ². Vector dimensions and index design therefore belong in the capacity worksheet alongside document count. A team that changes the representation of each document has changed its test, even if the number of documents remains constant. Compare like with like when discussing a pilot result.

Partitions also matter. Microsoft's guidance says storage and vector quotas change as partitions are added or removed ². A plan should state the tested partition configuration rather than presenting a quota as permanent. If the accounting firm scales the service, it must re-read the service and index statistics in the new configuration. An estimate copied from the old setup is no longer a measured fact.

The practical output is a range with assumptions: sample size, vector field design, update pattern, algorithm choice and partition count. There is no sourced universal number of bytes per document in these materials. If management asks for a fixed bill or guaranteed headroom from the 100,000 count alone, the answer is that the test index and service statistics must supply the missing evidence.

Query access: the reader role

Microsoft's Search Index Data Reader role permits querying indexes ³. That is the relevant role for an application that must retrieve documents to answer a user. It does not make every member of the project team an administrator. The query role belongs to the application identity, followed by a test of the exact planned query path.

The permission test should include both a success and a refusal. First, the application should retrieve from the intended index. Second, it should fail to read an unrelated index when its grant is meant to be narrow. This is a practical check of the assignment's scope, not an assertion that a role name alone proves isolation. Record the successful and refused queries in the test record.

A retrieval system can return relevant text only from material it can access. The accounting firm should therefore map the document collection to the application's intended users before calling the pilot ready. A successful technical query is not a decision that every employee may see every record. The role grants documented by Microsoft are the technical starting point for that narrower business review ³.

Scope the role to one index

Microsoft documents how the Search Index Data Reader role can be scoped to an individual index ³. Use the Azure CLI, PowerShell or REST API to assign the role at single-index scope ³ when the application needs one project collection. Record the principal, role, target index and test date with that assignment. A later new index should not silently inherit a broad grant merely because the first prototype worked.

For a 100,000-document project, separate the three decisions: whether retrieval quality is good enough, whether measured capacity is available, and whether query access is narrow enough. The decisions use different evidence. A low vectorIndexSize does not prove answer quality; a good answer does not prove spare quota; a correct role name does not prove the assignment was scoped correctly.

What this cannot decide

The published measurements and roles do not decide whether the accounting firm needs a vector database, what its final cost will be, or whether every retrieved passage may be shown to every user. Those answers depend on its tested documents, questions, permissions and service configuration. The NIST and Eurostat definitions establish the retrieval pattern ^4,5; Azure's pages identify what to measure and which query role can be scoped ^1,2,3.

For related design decisions, compare AI agents for small businesses, agents with automation platforms, an agent opportunity score, and an accounts payable automation example. Each has a different job from measuring this index.

What to do next

The next step is a representative index with service and per-index statistics, plus a record of its configuration and measurements. Assign Search Index Data Reader to the application at the narrowest index scope that fits its task, then test an intended and an unintended query ^1,3. Repeat capacity measurements after updates before approving the full 100,000-document import ².