Choose an Azure service for vector search

Vector search is a way to find information stored in a database in the shape of vectors. Vectors are groups of numbers that represent features or characteristics of media, such as text or images. They capture semantic relationships within the information, which enables similarity search beyond exact keyword matching.

Azure provides multiple ways to store and search vectorized data. This article helps you choose the right Azure vector search service for your applications.

This article compares the following services based on their vector search capabilities:

• Azure AI Search
• Azure Cosmos DB for NoSQL
• Azure DocumentDB
• Azure Database for PostgreSQL
• Azure Managed Redis
• Azure SQL Database

To compare the system requirements for each service, see Choose a candidate service and Capability matrix.

Choose a candidate service

This section helps you select the best service or services for your needs. To narrow the choices, start by considering the system requirements.

Key requirements

To decide whether to use a traditional database solution or AI Search, consider your requirements and whether you can perform live or real-time vector searches on your data. If you frequently change values in vectorized fields, and if those changes need to be searchable in real time or near real time, a traditional relational or NoSQL database is the best fit for your scenario. Similarly, your existing database might be the best way to meet your performance target. However, if your workload doesn't require real-time or near-real-time vector searchability, and you can manage an index of vectors, you can use AI Search.

If you choose a traditional database solution, choose a database service based on your team's skill set and your existing databases. If you already use a database service, such as Azure Cosmos DB for NoSQL, that service might be the easiest solution for your scenario.

• Azure Cosmos DB for NoSQL is a good fit if you want to keep operational data and vector search in the same system and if you need full-text scoring, hybrid search, or built-in reranking. Its semantic reranker is in preview. When your application writes a record and its embedding together, you don't need to synchronize a separate search index before querying the updated item.

• AI Search is a good choice when you need a separate managed index for content from multiple sources, with integrated vectorization and search-specific features such as faceting and autocomplete.

• Azure Database for PostgreSQL supports horizontal scaling by using elastic clusters, a managed offering of the open-source Citus extension that supports horizontal sharding. This capability distributes vector data across multiple nodes, which can be useful for large vector datasets.

• Consider Azure Managed Redis when you need ultra-low-latency, in-memory vector search or when Redis is already deployed for caching or session management.

Each database service has unique capabilities and limitations for vector search. Check that your database type has the required functionality.

New services and extra database instances can increase cost and complexity. To reduce overhead, you can continue to use your existing design. Vector search in your current databases might be more cost effective than a dedicated vector search service.

Support for advanced retrieval features varies by service. Azure Cosmos DB for NoSQL and Azure DocumentDB provide native hybrid search that combines full-text and vector search by using reciprocal rank fusion (RRF). Azure Cosmos DB for NoSQL also provides a semantic reranker in preview. AI Search provides hybrid search and semantic ranking as managed search features. For services that don't provide these capabilities, implement the required ranking logic in your application or database code.

Capability matrix

The tables in this section summarize Azure vector search service capabilities. Compare the available services with your requirements. Some services are a better fit for specific scenarios, so consider the trade-offs shown in each table.

If you're working in Microsoft Fabric, you can use Real-Time Intelligence for vector similarity search (VSS) by using an eventhouse as a vector database. For more information, see the Fabric documentation.

Basic features

Native support for vector data types, approximate nearest neighbor (ANN) vector indexes, vector dimension limits, multiple vector fields, and multiple vector indexes varies across services. Your workload might require one or more of these features.

The following table shows the vector capabilities of each Azure service.

1. Azure DocumentDB supports vector search on embeddings.
2. pgvector, an extension of PostgreSQL, supports vector search. The pg_diskann extension offers DiskANN-based vector indexing for efficient ANN search at scale.
3. The RediSearch module in Azure Managed Redis provides vector search.
4. AI Search supports vectors.
5. SQL Database supports a vector data type.
6. OpenAI embedding models include 1,536 dimensions for text-embedding-ada-002 and for text-embedding-3-small, and 3,072 dimensions for text-embedding-3-large. Azure Vision multimodal embedding models have 1,024 dimensions for both image and text.
7. Vectors indexed by using the flat index type can have up to 505 dimensions. Vectors indexed by using the quantizedFlat or DiskANN index type can have up to 4,096 dimensions.
8. You can index vectors up to 16,000 dimensions by using DiskANN and product quantization. Hierarchical navigable small world (HNSW) or IVFFlat with half-precision supports vector indexes of up to 4,000 dimensions. Without compression, the default maximum vector dimension for indexing is 2,000. For more information, see the vector dimensions for Azure DocumentDB.
9. Vectors can have up to 16,000 dimensions. However, indexing by using IVFFlat and HNSW algorithms supports vectors with up to 2,000 dimensions.
10. AI Search supports Matryoshka Representation Learning-based dimension truncation. Text-embedding-3 models can reduce vector dimensions. For example, you can use 256 or 512 dimensions.
11. SQL Database supports a native vector data type with up to 1,998 dimensions.
12. Each Azure DocumentDB vector index targets one vector path. Create a separate vector index for each vector field that you need to query.
13. You can create multiple indexes in an Azure DocumentDB collection, but only one vector index can target a specific vector path.

Search methods

Workloads often need to combine vector search with full-text search or hybrid search. Hybrid search is a full-text search or semantic search combined with a vector search. When combined, hybrid search and reranking achieve high accuracy for workloads. You can manually implement hybrid search and reranking by using your own code, or you can consider how your vector store supports this workload requirement.

1. Semantic ranking reranks results of full-text and vector searches.
2. Azure DocumentDB supports search and query by using text indexes.
3. PostgreSQL supports full-text search.
4. Azure Managed Redis supports full-text search by using the RediSearch module, including text tokenization, stemming, and ranking.
5. SQL Server supports full-text search.
6. Azure Cosmos DB for NoSQL supports hybrid search that combines BM25 full-text scoring and vector search by using RRF. You can assign weights to the component rankings.
7. Azure DocumentDB natively supports hybrid search that combines full-text and vector search with reciprocal rank fusion.
8. Hybrid search isn't built in, but sample code is available.
9. Azure Managed Redis supports hybrid search by using VSS combined with attribute filtering on text, numeric, tag, and geo fields.
10. Hybrid search, which combines full-text search, vector search, and semantic ranking, is a feature in AI Search.
11. An example of hybrid search for SQL Database and SQL Server is available.
12. Azure Cosmos DB for NoSQL supports full-text search and full-text scoring.
13. The semantic reranker for Azure Cosmos DB for NoSQL is in preview. It can rerank vector, full-text, or hybrid query results through supported Azure Cosmos DB SDKs.

Vector data indexing algorithms

Vector data indexing is the ability to efficiently store and retrieve vectors. Indexing influences the speed and accuracy of similarity searches and nearest neighbor queries on data sources.

Indexes typically use either an exhaustive k-nearest neighbor (Ek-NN) algorithm or an ANN algorithm. Ek-NN performs an exhaustive search on all data points and returns the accurate k nearest neighbors. When searching a small amount of data, Ek-NN works in milliseconds. For larger datasets, you might experience latency.

DiskANN, HNSW, and IVFFlat are ANN algorithm indexes. Selecting the appropriate indexing strategy requires careful consideration of various factors such as the nature of the dataset, the specific requirements of the queries, and the available resources. DiskANN can adapt to change in the dataset and save computational resources. HNSW excels in systems that require fast query responses and can adapt to changes in the dataset. IVFFlat is effective in environments where hardware resources are limited or query volumes aren't high.

The following table shows the available vector data indexing types.

1. For more information, see Integrated vector store in Azure DocumentDB.
2. For more information, see DiskANN for Azure Database for PostgreSQL.
3. Native DiskANN vector indexing is in preview. For more information, see Vector search and vector indexes in the SQL Database Engine.
4. Azure Managed Redis supports Ek-NN search by using the FLAT index type for brute-force search.
5. Azure Managed Redis supports HNSW for ANN search. For more information, see VSS.
6. For more information, see Vector indexing policies.
7. Indexing applies to only one vector per path.
8. You can create only one index per vector path.
9. AI Search supports scalar and binary quantization to reduce vector size in a search index.

Similarity and distance calculation capabilities

Vector search supports cosine similarity, dot product, and Euclidean distance calculation methods. Use these methods to calculate the similarity or distance between two vectors.

Preliminary data analysis uses metrics and Euclidean distances so that you can extract a variety of data structure insights. Text classification generally performs better under Euclidean distances. Retrieval of the most similar texts to a given text typically functions better with cosine similarity.

Azure OpenAI embeddings rely on cosine similarity to compute similarity between documents and a query.

1. For more information, see the vector distance calculation for Azure Cosmos DB for NoSQL.
2. Azure Managed Redis supports cosine similarity, Euclidean distance, and inner product distance metrics. For more information, see VSS.
3. For more information, see the distance calculation examples for SQL Database and SQL Server.

Integration with Azure OpenAI and other components

You can link vector search to other Microsoft components. For example, Azure OpenAI helps you create vectors for your data and input queries for VSS.

1. Foundry Agent Service integration is provided through agent state storage.
2. Foundry Agent Service integration is provided through data, vector search, or tool access.
3. Foundry Agent Service integration is provided through knowledge retrieval and vector search.
4. The Azure AI extension is available.
5. AI Search includes a skill that vectorizes text chunks.
6. You can create a stored procedure for your embedding model deployment.
7. This service is supported as a memory connector and a vector database connector. For more information, see the C# documentation and the Python documentation.
8. This service is supported as a vector database connector. For more information, see the C# documentation and the Python documentation.
9. This service is supported as a memory connector and a vector database connector. For more information, see the C# documentation.
10. This service is supported as a vector database connector. For more information, see Using the Redis connector.
11. This service is supported as a memory connector and a vector database connector. For more information, see the C# documentation and the Python documentation.
12. This service is supported as a memory connector.

Operational considerations

The capability matrix identifies services that meet your functional requirements. When more than one service qualifies, compare how each option affects data placement, freshness, filtering, capacity, and embedding maintenance.

Data placement and freshness

Azure Cosmos DB for NoSQL, Azure DocumentDB, Azure Database for PostgreSQL, and Azure SQL Database can store embeddings with the workload's operational records. If your application generates an embedding and writes it with the record, both values are updated through the database write path. This design avoids a separate search index synchronization process.

AI Search maintains a search index that is separate from the source system. You can push documents to the index or use an indexer to pull data from a supported data source. A separate index lets you combine and shape content from multiple systems, and scale retrieval independently from transactional workloads. It also creates another copy of the searchable data. Account for the time between a source update and the corresponding index update.

Choose a colocated design when operational records change frequently and retrieval must use the updated values. Choose a separate search index when the corpus spans multiple systems or requires managed content extraction, enrichment, and vectorization.

Filtering and partitioning

Most production vector queries use filters to enforce tenant, security, document-set, or application boundaries. Evaluate filters with the vector search because they can affect both recall and latency.

• In Azure Cosmos DB for NoSQL, add supported predicates to the WHERE clause of a query that uses VectorDistance. A partition-key filter limits the search to the matching logical partition.
• In Azure DocumentDB, add supported filters to the cosmosSearch operator.
• In AI Search, create filterable non-vector fields and use vector filter modes to control whether the service applies a filter before or after vector retrieval.

Capacity and regional design

The services use different scaling and billing units, so list-price comparisons don't show the cost of a specific workload. Model index size, vector dimensions, query rate, update rate, replicas, partitions, and database throughput. Include the cost of the source database when you evaluate a separate search index.

Regional design also differs:

• Azure Cosmos DB provides built-in data distribution across Azure regions and supports multiple write regions.
• AI Search is a regional service. A multiregion AI Search design uses a search service in each region and requires a process that keeps the indexes aligned.

Keep embeddings current

Embeddings are derived data. Regenerate them when the source content changes or when you adopt a different embedding model.

AI Search indexers can orchestrate chunking and integrated vectorization for supported sources. For a database-centered design, your application or data pipeline performs those steps and writes the resulting vectors. A change feed or source event can start that process, but the new content isn't semantically searchable until the updated embedding is stored.

Contributors

Microsoft maintains this article. The following contributors wrote this article.

Principal authors:

• Yu Saito | Solution Engineer
• Miho Yamamoto | Senior Solution Engineer

Other contributors:

• Keita Onabuta | Senior Solution Engineer
• Manish Sharma | Principal Program Manager

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

• Intelligent applications and AI
• VSS by using Azure SQL and Azure OpenAI
• Native vector support in Azure SQL and SQL Server
• Vector database in Azure Cosmos DB
• VSS in Azure Managed Redis
• Vector search in Azure AI Search
• Vector search in Azure Cosmos DB for NoSQL

Related resources

• Understand data models
• Technology choices for Azure solutions