{"id":10095,"date":"2025-05-07T07:10:02","date_gmt":"2025-05-07T14:10:02","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cosmosdb\/?p=10095"},"modified":"2025-05-13T13:32:15","modified_gmt":"2025-05-13T20:32:15","slug":"azure-cosmos-db-with-diskann-part-4-stable-vector-search-recall-with-streaming-data","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cosmosdb\/azure-cosmos-db-with-diskann-part-4-stable-vector-search-recall-with-streaming-data\/","title":{"rendered":"Azure Cosmos DB with DiskANN Part 4: Stable Vector Search Recall with Streaming Data"},"content":{"rendered":"

Vector search with Azure Cosmos DB<\/span>\u00a0<\/span><\/h2>\n

In <\/span>Part 1<\/span><\/a> and <\/span>Part 2<\/span><\/a> of this series, we explored vector search with Azure Cosmos DB and best practices for scaling it to 1 billion vector datasets while maintaining low query latency. In <\/span>Part 3,<\/span><\/a> we saw how we can create efficient sharded DiskANN indices for multi-tenant apps.<\/span>\u00a0<\/span><\/p>\n

In Part 4, we\u2019ll look at the effect that s<\/span>treaming ingestion, <\/span><\/i>a stream of inserts, deletes, and replaces of vectors in the database, has on the quality of the vector index. This is unlike the often reported single-shot ingestion where data is ingested once in bulk and recall is measured at the end when the index is built. Ideally, a vector index should always provide consistently high recall, including after a long stream of updates. Handling streaming scenarios tends to be challenging for many vector indexes, but we\u2019ll see that DiskANN in Azure Cosmos DB is able to handle this with high accuracy and low latency, all while maintaining cost-efficiency. <\/span>\u00a0<\/span><\/p>\n

Why is the streaming scenario so important?<\/span>\u00a0<\/span><\/h2>\n

Most real-world scenarios that use vector databases follow patterns of streaming ingestion:<\/span>\u00a0<\/span><\/p>\n