An Azure search service with built-in artificial intelligence capabilities that enrich information to help identify and explore relevant content at scale.
Hello Mihai !
Thank you for posting on Microsoft Learn Q&A.
Azure Search marks docs as deleted and reclaims disk during background merges. Microsoft docs say the physical deletion runs every few minutes, but the portal metrics can lag. If it’s still 13.7 GB after several days, it usually means either the deletes never actually reached the index, or you’re counting other storage that don’t shrink the way you expect.
https://learn.microsoft.com/en-us/azure/search/search-howto-reindex
If you removed files at the source, Search won’t remove them unless your indexer is configured to detect deletions otherwise, you must send @search.action: "delete" for the document keys. With Blob, the indexer only deletes when it sees the blob in a soft deleted state during a run and if you hard deleted blobs, set up soft delete detection or push explicit deletes.
https://learn.microsoft.com/en-us/azure/search/search-how-to-index-azure-blob-changed-deleted
Run your indexer with delete detection enabled (or push @search.action: "delete" by key). If you used Blob and hard-deleted files, flip to native soft delete and re-run the indexer so Search can see and purge them.
Deleting an index reclaims its storage immediately, unlike document-level deletes that wait on background compaction.
Vector indexes consume separate quota/memory and contribute to total storage and you can use the portal columns (“Vector index quota usage”, “Total storage size”) to spot the culprits.