Throughput and completeness are separate goals
A museum catalog may index thousands of exhibit descriptions from blob storage while periodically accepting large new photograph collections. It is tempting to fix an ingestion delay by changing one performance field and declaring the problem solved when a run finishes sooner. Azure AI Search indexers expose a batchSize parameter, but speed and completeness must be measured separately. A larger batch can alter resource use or failure behavior, while a smaller batch may incur more requests. Neither setting guarantees that every restricted or unusual document was indexed correctly. Begin with a reproducible data slice and explicit coverage criteria rather than arbitrary tuning.
Locate batchSize in the indexer parameters
Microsoft documents batchSize in the indexer parameters object alongside settings such as maxFailedItems and maxFailedItemsPerBatch. First identify the indexer, underlying data source, target index, service tier, field mappings, and any skillset before considering a change. Verify that the operation uses a supported API version and that an administrator has permission to modify the indexer. The correct value can depend on document size, enrichment workload, and service capacity; avoid presenting one number as a universal best practice. Record the existing configuration, not just the one field that attracted attention during troubleshooting.
Take a baseline that can be compared
Use recent execution history to record start and end times, document counts, warnings, errors, and which collections were expected to appear. Choose a small representative sample containing short descriptions, larger text records, records with non-ASCII accession numbers, and known difficult inputs. Do not assume that a green status equals a full index. Compare source inventory, index document keys, and retrieval for critical specimens. If there are preexisting failures, document them before the tuning trial so a change does not take credit for unrelated repairs. Keep source contents and access-sensitive fields in a restricted evaluation environment.
Change one variable at a time
A controlled test should alter batchSize while keeping schema, source records, indexer configuration, failure thresholds, query workload, and permissions as stable as practical. Obtain a change approval and use an appropriately isolated staging index if available. Avoid running an unplanned full reset or changing several configurations simultaneously; doing so makes the effect of batchSize impossible to interpret. With production data, preserve the existing indexer JSON and a rollback path. Do not hardcode a speculative “fastest” value. Instead select a documented supported configuration and measure it against the baseline using the same evaluation slice.
Watch for errors, retries, and skipped documents
Azure indexers can have per-document failures and warnings even when parts of a batch are processed. Microsoft documents maxFailedItems and maxFailedItemsPerBatch as failure-tolerance controls. These should be reviewed, not casually raised to conceal a problem during performance testing. Check execution status for error details and document keys where available, and differentiate unsupported inputs from temporary service load. If a batch fails, the workflow needs a clear rule for triage and recovery. A quicker run that silently omits conservation warnings or restricted-access metadata is not an improvement for an archival search system.
Interpret document counts with a source ledger
A source collection can contain blobs that should not become search documents, such as audio masters, unsupported binary types, or intentionally excluded drafts. Therefore the count of source files may not equal the count of indexed documents. Build an explicit inclusion map: eligible sources, exclusions, expected keys, successfully indexed records, and unresolved failures. If indexing applies one-to-many parsing, count the resulting child records according to the documented mode rather than pretending one blob always creates exactly one index document. BatchSize affects processing groups, not the catalog’s content policy. Preserve any rights and permissions filters during comparison.
Understand what a larger batch can change
Increasing batchSize may group more documents into one processing request, but actual throughput is also affected by source latency, skillset cost, record size, search units, and service limits. A change could reduce per-request overhead in one scenario and increase memory pressure or timeouts in another. Do not invent performance percentages or imply that a diagram reflects a live benchmark. Use conceptual side-by-side queues to explain the tradeoff, then rely on real authorized run histories to decide whether the change helped. If the system remains constrained, examine bottlenecks other than batchSize instead of endlessly increasing it.
Keep a clear boundary around private catalog fields
Indexer tuning does not change who is authorized to read search results. A public exhibit kiosk should still return only approved fields and apply rights filters enforced by the application and index configuration. If large batches contain sensitive records, monitor logs without copying full document bodies into unapproved analytics. Verify that indexer authentication to the data source and any private network requirements still work. A query returning a document is not proof that it should have been disclosed. Schedule an independent access-control check after a configuration change to avoid confusing operational success with privacy validation.
Plan recovery for partial or interrupted runs
If a test run fails or exceeds its execution window, preserve the error record and determine whether incremental indexing can continue from change detection. Resetting an indexer is a separate and potentially expensive decision; it is not required after every batchSize adjustment. Before a reset, check how the data source tracks updates, how failures are reconciled, and which external sources are still accessible. An incomplete run should have an owner and a documented retry decision. Do not silently mark missing documents as “not relevant” merely to make the success count fit expectations.
Decide using coverage, latency, and review cost
The release note should compare the same representative source set under the old and new batch configuration, show errors and warnings, note source and index document counts, and document any query-side regressions. Use clear labels for observed evidence versus hypothesized effects. A qualified reviewer should sign off on both operational throughput and preservation of critical records. If the new setting produces ambiguous coverage, retain the safer known configuration while investigating. This article is a documentation-based method and does not claim a measured speedup or a tested Microsoft subscription.
How We Research
We used these named official references (checked November 11, 2026): Microsoft Learn, Create an indexer; Microsoft Learn, Azure Blob indexer; Microsoft Learn, Indexer errors and warnings. We checked the indexer parameters and failure handling in current Microsoft Learn guidance, using a hypothetical source-to-index ledger rather than measured throughput. This is documentation-based instructional analysis, not a product benchmark, a hands-on integration, or a test of a real museum environment. Scenarios and all illustrations are hypothetical; we did not measure accuracy, throughput, file availability, granted permissions, or actual delivery. Before deployment, an authorized operator should recheck API versions, limits, identity scope, prices where relevant, and institution-specific retention and approval rules. We make no claim that any depicted response, screenshot, dataset, or user consent occurred in production.
Frequently Asked Questions
No. It is an indexer processing setting, not a query result limit. The parameter sits in an indexer configuration, not a search request.
No. Performance depends on workload, enrichment, service capacity, and failures. Inspect service limits and realistic data sizes before tuning.
Not as a substitute for diagnosing failures. Review skipped document IDs and required catalog coverage. The failure budgets affect whether indexing continues after errors.
No. Treat indexer updates, resets, and index deletion as separate operations. Run and reset are separate administrative operations.
Compare run metrics and coverage of required source records, warnings, and access controls. Verify both speed and the records that must remain searchable.