Skip to article
AI and Machine Learning Azure AI Search

Search partition

A search partition is a capacity unit in Azure AI Search that provides storage and indexing resources for indexes. Increasing partitions expands index storage and can improve throughput for data ingestion and some query workloads. It is configured on the search service capacity model.

Source: Microsoft Learn - Estimate and manage capacity of a search service Reviewed 2026-05-23

Exam trap
Adding partitions to fix query concurrency when replicas, not storage capacity, are the actual bottleneck.
Production check
Show the service and record SKU, partitions, replicas, provisioning state, and location before approving scaling.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
Azure AI Search partition, Azure Search partition, search service partition, search capacity partition, partition count, search unit partition
Difficulty
intermediate
CLI mappings
5
Last verified
2026-05-23
Review level
premium
Article depth
field-manual-template-specs
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

A search partition is one way an Azure AI Search service gets more room and data-processing capacity. Replicas are usually about query concurrency and availability, while partitions are mainly about storage and how much index data the service can handle. When an index grows because of many documents, vectors, or retrievable fields, partitions may become necessary. They are not free, and adding them is a capacity decision that should be tied to actual index size, ingestion load, and growth forecasts.

Why it matters

Search partitions matter because capacity limits can appear suddenly when indexes grow. Vector fields, semantic workloads, large retrievable documents, and duplicated migration indexes all increase storage pressure. If a service runs out of room, ingestion fails and users see stale or incomplete search results. Adding partitions can solve capacity pressure, but it increases cost and may not fix query concurrency if replicas are the real bottleneck. Architects need to distinguish storage, indexing throughput, and query availability before scaling. The right partition count protects growth; the wrong one hides a design problem with spend. This choice turns search growth into an explicit architecture and cost decision.

Technical context

In Azure architecture, partitions belong to the Azure AI Search service capacity model. The service has a SKU, replica count, and partition count, and those values combine into search units. Partitions affect how index storage and some workload processing are distributed inside the service. They sit at the control-plane service resource level, while individual indexes consume that capacity. Partition decisions connect FinOps, performance engineering, storage growth, vector search design, indexing throughput, service limits, and availability planning.

Exam context

What to know

Explains the Azure AI Search concept in operational terms with security, reliability, cost, performance, CLI, and case-study context.

Compare with

Search replica Search service SKU / tier

Where it is used

Where you see it

  1. In search service properties, partitionCount appears beside replicaCount, SKU, location, provisioning state, and public network settings for capacity review. during search partition production support reviews.
  2. In Azure Monitor metrics, storage utilization, document count, throttling, and indexing failures signal when partition headroom is becoming a production risk. during search partition production support reviews.
  3. In cost reports, higher search units reflect the combined effect of SKU, replicas, and partitions after a scaling change. during search partition production support reviews.
  4. In deployment or migration plans, temporary parallel indexes reveal whether partition capacity can handle rebuilds without blocking ingestion or rollback. during search partition production support reviews.

Common situations

  • Increase capacity for vector-heavy RAG indexes when storage growth threatens ingestion and freshness.
  • Plan parallel index rebuilds or blue-green search migrations without running out of service storage.
  • Separate capacity decisions by diagnosing whether storage, indexing throughput, or query concurrency is the actual bottleneck.
  • Control recurring spend by right-sizing partition count after deleting obsolete indexes or reducing retrievable fields.
  • Create capacity evidence for launch reviews using document count, storage utilization, growth forecast, and search unit cost.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Media archive adds headroom for vectorized footage search Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A streaming media archive added vector search over transcripts and scene summaries, and the search service approached its storage limit during a documentary launch.

Goals
  • Prevent ingestion failures before the launch catalog went live.
  • Keep a parallel rollback index during schema migration.
  • Avoid unnecessary query replicas if storage was the only pressure.
  • Create FinOps evidence for temporary capacity growth.
Approach using Search partition

The platform team reviewed index statistics for transcript, scene, and metadata indexes and confirmed storage, not query concurrency, was the bottleneck. They increased Search partition count for the service before building a parallel vector index, leaving replica count unchanged. Operators tracked document count, storage size, indexing duration, and query p95 during the migration. After launch validation, they deleted the obsolete index and reviewed whether the extra partition was still needed. Cost tags and a change record tied the temporary capacity increase to the documentary launch project.

Potential outcomes
  • Indexing completed 11 hours before launch instead of failing at capacity limits.
  • The rollback index stayed available through the release window.
  • Query p95 changed by less than 4 percent because replicas were correctly left unchanged.
  • Partition count was reduced after cleanup, avoiding roughly $18,000 in annualized waste.
What to learn

A Search partition decision should be tied to the capacity bottleneck, not a vague desire to make search bigger.

Scenario 02 Engineering design platform plans CAD search growth Scenario, objectives, solution, measured impact, and takeaway.
Scenario

An engineering collaboration platform indexed CAD metadata, drawings, and vector embeddings, but storage growth doubled after customers enabled image-derived annotations.

Goals
  • Forecast partition needs before enterprise customer onboarding.
  • Keep indexing fresh while large design repositories synchronized.
  • Separate storage scaling from query-availability scaling.
  • Document cost impact for customer-specific chargeback.
Approach using Search partition

The cloud architecture team exported index statistics per customer workspace and compared storage growth against the search service SKU limits. They modeled partition requirements for the next two onboarding waves, including temporary parallel indexes used during schema upgrades. Azure CLI captured current partition and replica counts, while metrics showed indexing duration increased during annotation imports. The team increased partitions for the shared enterprise service, kept replicas stable, and added chargeback reporting based on indexed storage and workspace growth. Obsolete preview indexes were deleted before the final capacity increase. The runbook also recorded owner, baseline, and rollback evidence for reviewers.

Potential outcomes
  • Onboarding capacity risk was identified six weeks before the largest customer migration.
  • Indexing freshness stayed under the four-hour service target during annotation imports.
  • Deleted preview indexes reduced required partitions from five to four.
  • Chargeback reports explained 92 percent of search spend by customer workspace storage.
What to learn

Search partitions make capacity planning concrete when indexed storage grows faster than the original architecture expected.

Scenario 03 Specialty marketplace right-sizes search after seasonal migration Scenario, objectives, solution, measured impact, and takeaway.
Scenario

A specialty marketplace scaled partitions for a holiday blue-green index migration, then forgot to reduce capacity after the old catalog index was removed.

Goals
  • Recover wasted recurring search spend after migration.
  • Keep enough headroom for seasonal catalog growth.
  • Avoid reducing partitions below the rollback safety margin.
  • Create a monthly capacity review for search services.
Approach using Search partition

The FinOps team noticed search unit cost remained elevated two months after the holiday release. Operators pulled service capacity, index statistics, and document counts, then confirmed the old parallel catalog index had been deleted. Storage utilization was low enough to reduce Search partition count while keeping forecasted headroom for spring inventory. The team scheduled the change during a low-traffic window, verified ingestion and query metrics afterward, and added a monthly workbook comparing partitions, replicas, storage utilization, and largest indexes. Future migrations required an explicit partition reduction checkpoint. The runbook also recorded owner, baseline, and rollback evidence for reviewers.

Potential outcomes
  • Monthly search spend dropped 27 percent without changing user-facing latency.
  • Storage headroom remained above 35 percent for forecasted spring catalog growth.
  • No indexing failures or query regressions occurred during the reduction window.
  • The capacity review caught two smaller over-provisioned search services the next month.
What to learn

Search partitions are a recurring-cost lever, so operators should reduce them when migration headroom is no longer needed.

Azure CLI

For search partitions, Azure CLI is the safest way to turn capacity decisions into repeatable evidence and controlled changes. The portal can show the count, but CLI lets me capture current SKU, replicas, partitions, location, resource ID, and provisioning state before a change. It also fits approvals and rollback plans because the exact update command can be reviewed. After ten years of Azure work, I do not scale search blindly. I compare metrics, index stats, cost impact, and whether replicas or schema cleanup would solve the real problem first. That habit protects teams from expensive changes made on incomplete evidence.

Useful for

  • Show current partition count, replica count, SKU, and provisioning state before capacity review.
  • Update partition count during an approved scaling window after confirming cost and service limits.
  • Fetch index statistics to connect partition pressure with document count and storage growth.
  • Compare partitions across development, staging, and production to detect capacity drift before migrations.
  • Export diagnostic settings and metrics evidence when ingestion failures suggest storage capacity pressure.

Before you run a command

  • Confirm tenant, subscription, resource group, search service, region, SKU, current replicas, current partitions, and output format.
  • Check permissions because updating partition count is a control-plane change with direct cost and availability implications.
  • Review service limits, index storage, migration windows, destructive cleanup plans, and whether provider registration is healthy.
  • Validate whether replicas, schema design, or query tuning is the better fix before increasing recurring partition cost.

What the output tells you

  • Service output shows partitionCount, replicaCount, SKU, location, hosting mode, public network access, and provisioning state.
  • Index statistics show document count and storage size, helping connect capacity pressure to specific indexes or migrations.
  • Cost evidence shows how search units changed after scaling because partitions multiply with replicas under the chosen SKU.
  • Metric output helps distinguish storage pressure and indexing failures from query latency issues that may need replicas or tuning.

Mapped commands

Search partition operational checks

direct 
az search service show --name <search-service> --resource-group <resource-group> --query "{sku:sku.name,replicas:replicaCount,partitions:partitionCount,location:location,provisioningState:provisioningState}"
az search servicediscoverAI and Machine Learning
read-only Microsoft Learn 
az search service update --name <search-service> --resource-group <resource-group> --partition-count <count>
az search serviceconfigureAI and Machine Learning
cost-impacting Microsoft Learn 
az rest --method get --url "https://<search-service>.search.windows.net/indexes/<index-name>/stats?api-version=2024-07-01" --headers "api-key=<admin-key>"
az restdiscoverAI and Machine Learning
read-only Microsoft Learn 
az monitor metrics list --resource <search-service-resource-id> --metric SearchLatency,ThrottledSearchQueriesPercentage
az monitor metricsdiscoverAI and Machine Learning
read-only Microsoft Learn 
az monitor diagnostic-settings list --resource <search-service-resource-id>
az monitor diagnostic-settingsdiscoverAI and Machine Learning
read-only Microsoft Learn

Architecture context

As an Azure architect, I look at partitions after studying index size, document growth, vector dimensions, rebuild strategy, and traffic pattern. Partitions are not a magic performance switch. They are part of a capacity plan that balances replicas, partitions, SKU, indexes, and workload separation. A large RAG index with vector fields may need partitions for storage, while a busy public search site may need replicas first. Parallel migration indexes can temporarily double storage needs, so capacity planning should include deployment windows and rollback. The goal is predictable headroom, not emergency scaling. That plan should also state when temporary headroom will be removed.

Security
Security impact is indirect because partitions do not change who can query, administer, or access data. Risk still appears during scaling operations. Engineers need control-plane permission to update the search service, and that permission should be restricted because capacity changes affect cost and availability. Larger capacity can hold more copied sensitive data, so index governance and retention still matter. Private endpoints, local authentication settings, admin-key handling, and diagnostic access are unchanged by partition count. Treat partition changes as privileged infrastructure changes with approval, logging, and rollback evidence. Approvals should record who changed capacity and what copied data remains stored. The risk should be written down before the change is approved.
Cost
Cost impact is direct because partitions contribute to search units, and search units determine service billing with the selected SKU. Adding partitions for storage headroom can be necessary, but unused capacity becomes recurring waste. Vector-heavy indexes, parallel rebuilds, and many retrievable fields can push teams toward more partitions. FinOps owners should track partition count, replica count, SKU, index storage, forecast growth, and migration windows. Sometimes the cheaper fix is schema cleanup, fewer retrievable fields, archived indexes, or separate services for workloads with different capacity needs. Rightsizing after migrations is as important as scaling before them. FinOps owners need measurable evidence before accepting recurring spend.
Reliability
Reliability impact is practical. Adequate partitions provide storage headroom so indexing does not fail when documents, vectors, or parallel indexes grow. Too little capacity causes ingestion failures and stale search. Too much emergency scaling without testing can still leave query availability issues if replicas are insufficient. Operators should monitor storage utilization, document count, indexing failures, and growth trend before users feel the limit. Capacity plans should include migration spikes, regional constraints, SKU limits, and rollback indexes. Reliability means the service has enough room to keep search fresh. Capacity reviews should happen before large rebuilds, not after failed ingestion. Operators should record baseline behavior and expected recovery evidence.
Performance
Performance impact depends on the bottleneck. More partitions can help indexing throughput and large-index handling, but they do not replace replicas for query concurrency or high availability. If latency comes from broad filters, semantic ranking, vector search, or oversized payloads, partition scaling may have limited effect. Measure before changing: index storage, document count, indexing duration, query p95, throttling, and replica load. A partition increase should be judged by whether it improves the specific pressure point, not by a general hope that more capacity makes everything faster. Capacity decisions should be tested with the workload pattern that actually caused concern. Performance review should include p95 behavior and worst-case user journeys.
Operations
Operators inspect partitions through service properties, capacity metrics, index statistics, document counts, storage utilization, and indexing error patterns. They decide whether to scale partitions after comparing current storage, forecast growth, vector expansion, and any temporary migration indexes. Changes should be scripted, approved, and recorded with before-and-after metrics. Runbooks should also verify replicas, SKU limits, and application impact, because a partition change alone may not fix latency or availability. After scaling, operators confirm ingestion recovery, query health, and cost tracking tags. Operators should record the business reason, forecast, and expiry date for extra capacity. The support path should include owner, evidence, and next action.

Common mistakes

  • Adding partitions to fix query concurrency when replicas, not storage capacity, are the actual bottleneck.
  • Ignoring vector and retrievable field growth until ingestion fails because the service runs out of storage headroom.
  • Leaving extra partitions after a parallel migration index is deleted, creating quiet recurring waste.
  • Scaling without documenting baseline storage, query latency, indexing duration, cost impact, and rollback criteria.