# azure-search-vector-samples: four languages showing how Azure AI Search vector search works > This repository is a set of samples rather than a library, showing vector search in Azure AI Search across Python notebooks, .NET, Java and JavaScript, in two shapes: call Azure OpenAI yourself to vectorize, or let an indexer skillset do it during indexing. It also flags the breaking changes between the 2023-07-01-Preview REST API and later versions. **Azure/azure-search-vector-samples** — A repository of code samples for Vector search capabilities in Azure AI Search. - Repository: https://github.com/Azure/azure-search-vector-samples - Website: https://azure.microsoft.com/products/search - Stars: 908 · Forks: 375 - Language: Jupyter Notebook - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/azure-azure-search-vector-samples ## Two architectures repeated in four languages The repository provides Python, C#, REST and JavaScript code samples for vector support in Azure AI Search, and its structure is more useful than its length. Every language directory contains the same two scenarios, and the difference between them is where the vectorization happens. The first scenario is manual embedding. The .NET DotNetVectorDemo is a console app that calls Azure OpenAI to vectorize data and then calls Azure AI Search to create, load and query vector data. The Java demo-vectors sample does the same thing. In the JavaScript folder, the azure-search-vector-sample.js script calls just Azure OpenAI and is used to generate embeddings for fields in an index, while docs-text-openai-embeddings.js is the end-to-end program that creates, loads and queries an index, and query-text-openai-embeddings.js generates the embedding for a vector query. The second scenario is integrated vectorization. DotNetIntegratedVectorizationDemo and demo-integrated-vectorization call Azure AI Search to create an index, an indexer, a data source and a skillset. An Azure Storage account provides the data, Azure OpenAI is called by the skillset during indexing, and again during query execution to vectorize text queries. The distinction is the single most important thing in this repository. In the manual shape your application owns the embedding step and the pipeline is: read data, call Azure OpenAI, write the vectors into the index, then embed each query at request time. In the integrated shape Azure AI Search owns it: the indexer pulls from storage and the skillset calls Azure OpenAI on the way in, and query embedding happens inside the service. Seeing the same two shapes in four languages makes the trade-off obvious. Integrated vectorization removes the embedding plumbing from your application but binds the pipeline to an Azure AI Search indexer and skillset configuration. Manual embedding keeps that logic in code, where it is testable and portable, at the cost of you running the loop. ## The Python notebooks are where the chunking details live The demo-python directory is described as a growing collection of notebooks that demonstrate aspects of vector search support, including data chunking and embedding of both text and image content and queries, using a variety of frameworks and techniques. That description is the reason the notebooks are the most valuable part of the repository for a newcomer. Chunking is where most vector search projects quietly go wrong, and it is the part a console app sample is worst at showing. Splitting a document into chunks, deciding the chunk size and overlap, then embedding each chunk separately, is a decision that changes retrieval quality more than the choice of vector store does. The note that the notebooks cover embedding of both text and image content matters too, because image and text vectors live in separate modalities. An image embedding and a text embedding of the same concept are not comparable unless the model was trained to align them, which is a different setup from a text model producing a vector for a text query against text chunks. The repository also has a data/ directory at the root, and a .devcontainer/ directory, so the notebooks run in a defined environment rather than depending on whatever the reader has installed. Because the notebooks are described as a growing collection, and because the primary language of the repository is recorded as Jupyter Notebook, this is the part of the repository designed to be read and run interactively rather than copied. The console apps in the other three languages are the ones designed to be copied. ## Quantization and the option to stop storing vectors The .NET QuantizationAndStorageOptions sample is the one that goes beyond a straightforward vector demo, and it is worth reading for two separate features. The first is narrow data types and built-in scalar quantization, which reduces vector index size in memory and on disk. Scalar quantization trades precision for size, and the reduction is meaningful for a vector index because the vectors dominate the footprint. A vector field declared with a narrow type rather than the full float type is one of the cheaper ways to cut the cost of a vector index, and it changes the accuracy of the ranking slightly, which is the trade you are making. The second is disabling the storage of vectors returned in query responses. The sample documentation notes you do not need this if you are not returning vectors in a query. This sounds trivial and is not. A vector index stores vectors, and the default behaviour appears to also return them to the client, so a query response carries a payload proportional to the number of results times the vector size. For a search interface that only shows text, that is a large amount of network traffic and deserialization work for nothing. Between them these two features point at the same lesson: in a vector search system the index is the expensive part, and the sample set covers how to make it smaller and how to move less of it around. This is also the sample to study if you are comparing against another vector database, because the knobs it exposes, data type width, quantization and response payload, are the same knobs any vector store has, and the differences between implementations show up in what they let you set. ## The 2023-07-01-Preview breaking changes still apply to the SDKs The most consequential line in the documentation is the warning at the top. There are breaking changes from REST API version 2023-07-01-Preview to newer API versions, and these breaking changes also apply to the Azure SDK beta packages targeting that REST API version. The documentation links to Upgrade REST APIs for migration guidance. This is a compatibility trap rather than a version note. A project written against the 2023-07-01-Preview API, or against an SDK beta package built on it, does not work unchanged against a current API version, and the failure surfaces at the service rather than at build time. Samples in this repository that were written for the older version will need the migration applied, and so will anything you copied from them earlier. The second caveat is the preview terms. Preview features are available under Supplemental Terms of Use. That is a legal distinction rather than a technical one, and it matters for anyone planning to put a sample into production: the feature set on a preview API is not the feature set you will be held to later. Both caveats point the same way. Read the migration guidance before running any of this against a current resource, and treat these samples as illustrations of shape rather than as code to paste into a system that will outlive the preview. ## Where to go once the samples have done their job The documentation links a set of other repositories that cover different scales of problem, and the differences between them are instructive. azure-ai-search-lab is a learning and experimentation lab for trying out AI-enabled search scenarios in Azure. It includes a web application front end that runs searches with a range of options, from simple keyword search through semantic ranking, vector and hybrid search, and generative AI answering, so you can quickly see what each option does to results and how the approaches compare. That is a different tool from this repository, which shows how to build one approach well. chat-with-your-data-solution-accelerator is a template that deploys multiple Azure resources for a custom chat-with-your-data solution, presented as a production-ready solution implementing coding best practices. This is the deployment-shaped counterpart to the samples here. The Azure Search OpenAI Demo is a Retrieval-Augmented Generation sample running in Azure, using Azure AI Search for retrieval and Azure OpenAI models to power ChatGPT-style Q&A, with a vectors branch to use vector retrieval, and there is a C# variant of the same pattern on a feature branch. The OpenAI ChatGPT retrieval plugin repository covers the case where the client is not your own application but the ChatGPT plugin interface, with Azure AI Search as an official vector database. Two more sit further out. A React web app template combines Azure OpenAI for text search with the Cognitive Services Florence Vision API for image search, and the Azure Cognitive Search Comparison Tool is listed without further description. So the progression is clear: this repository shows the primitives, the lab lets you compare approaches in a UI, and the accelerator and the demo show what a deployable system looks like. The documentation also points at the Azure AI Search documentation pages on vector search overview, hybrid search overview, creating and querying a vector index, the vector search algorithms page and the REST API reference, plus the RAG overview, which is the conceptual starting point for most people arriving at this. ## Repository shape, licence and maintenance state The top level of the repository is small. There are the four language directories, demo-python, demo-dotnet, demo-java and demo-javascript, a data/ directory, a .devcontainer/ and .vscode/ directory, a SECURITY.md, a LICENSE.md and a package.json. That package.json is telling. Its entire dependencies block is one entry, dotenv at 16.4.7, and there are no scripts at all. The root of a repository that contains .NET, Java and Python projects is not the build root for any of them; it exists so the JavaScript samples can load environment variables from a .env file. A repository-level package.json in a multi-language samples repo is a convenience, not a build system, and it is worth knowing that before you go looking for a single command to build everything, because there is not one. The licence field on the repository says MIT, with a LICENSE.md at the root. That is a permissive licence with attribution requirements and no copyleft obligations, and for sample code that people copy into their own projects it is about as low friction as a licence gets. This is not legal advice, but if you are copying a sample into a commercial product the terms are the simple case. On maintenance, the last push was on 2026-10-03, so the tree is being worked on. There are no GitHub releases, which is normal for a samples repository where the versioning lives in the Azure API versions rather than in the code, and it means there is no changelog to consult when a sample changes shape. The SECURITY.md is the file to read if you plan to report a problem, and given that these samples handle Azure OpenAI keys and Storage account credentials through environment variables, that is a file that should exist and be taken seriously. ## Conclusion The samples suit a developer evaluating Azure AI Search vector search who wants to see the same feature implemented in four languages and in two architectural shapes before committing to an approach, and the notebooks in demo-python are the fastest way to understand the chunking and embedding flow. They do not suit a production project looking for a supported client library, since this is documentation with sample code and the dependency list in the root package.json is a single dotenv entry, and they do not reflect the current REST API without migration work, since the 2023-07-01-Preview breaking changes still apply to the SDK beta packages. Before copying any of it, read the Upgrade REST APIs guidance and check that your Azure AI Search and Azure OpenAI resources match the API version the sample targets. ## FAQ ### What does the azure-search-vector-samples repository contain? Python, C#, REST and JavaScript code samples for vector support in Azure AI Search. The demo-python directory holds notebooks covering data chunking and embedding of text and image content and queries, and the other three directories hold console apps that vectorize with Azure OpenAI and then create, load and query vector data in Azure AI Search. ### What is the difference between integrated vectorization and manual vectorization in these samples? In the manual shape the application calls Azure OpenAI to vectorize data and then writes vectors into the index. In the integrated shape, Azure AI Search creates an index, indexer, data source and skillset, an Azure Storage account provides the data, and the skillset calls Azure OpenAI during indexing and again during query execution to vectorize text queries. ### Which REST API version do the azure-search-vector-samples target? The documentation warns that there are breaking changes from REST API version 2023-07-01-Preview to newer API versions, and that these changes also apply to the Azure SDK beta packages targeting that version. It links the Upgrade REST APIs page for migration guidance, and notes that preview features are available under Supplemental Terms of Use. ### What does the QuantizationAndStorageOptions sample demonstrate? It is a .NET console app that shows narrow data types and built-in scalar quantization to reduce vector index size in memory and on disk, and it disables storage of vectors returned in query responses, which you do not need if you are not returning vectors in a query. ### What licence does azure-search-vector-samples use? MIT, with a LICENSE.md file at the repository root. The root package.json carries a single dependency, dotenv at 16.4.7, and no build scripts, since each language directory is built separately. ## Sources - [Azure/azure-search-vector-samples on GitHub](https://github.com/Azure/azure-search-vector-samples) - [Issues](https://github.com/Azure/azure-search-vector-samples/issues) - [License: MIT](https://github.com/Azure/azure-search-vector-samples/blob/main/LICENSE) - [Project website](https://azure.microsoft.com/products/search) - [README](https://github.com/Azure/azure-search-vector-samples/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/azure-azure-search-vector-samples