Azure SQL Database Vector Search Goes GA: DiskANN Indexes, Syntax and Production Limits

There is one caveat. When we checked, Microsoft's own technical reference pages still carried the Preview label. We cover that in detail below.

What went GA​

The update covers two T-SQL features working together:

• CREATE VECTOR INDEX builds an approximate index on a column of the vector data type.
• VECTOR_SEARCH runs an approximate similarity search against that index using a query vector you supply.

According to the announcement text, as indexed by the BI & Beyond roadmap tracker, the pair supports ANN search for semantic search, RAG, recommendation systems and image search. The indexes are built on the DiskANN algorithm and let you combine vector search with ordinary relational queries and filters inside Azure SQL Database. Microsoft's pitch is that you can build AI features on enterprise data without a separate vector database, while keeping Azure SQL's existing security, reliability and governance.

It helps to be clear about what is new. The native vector data type and functions such as VECTOR_DISTANCE were already GA. Microsoft's Azure SQL Dev Corner blog announced that milestone in November 2025 and noted that DiskANN-based vector indexing is currently available in private preview for Azure SQL and in public preview for SQL Server 2025. This September's GA covers the indexing and approximate search layer, which is the part that makes vector queries practical at scale.

Section summary: Storing vectors and computing distances was already GA. As of September 28, indexed ANN search through CREATE VECTOR INDEX and VECTOR_SEARCH is GA too, for Azure SQL Database specifically.

How the preview got here​

The feature went through a noticeably rough preview:

The first public preview had a serious catch. The Azure SQL team later admitted it in a blog post that asked, with some candour, whether readers remembered that once you created the index, your table became read‑only? The team explained that we shipped early because the demand for Vector search in SQL was overwhelming.

Tables that freeze once indexed are fine for a static document archive. They don't work for a product catalogue that changes hourly. The upgrade introduced a new index format with full DML support. It also added what the team described as iterative filtering – filters are applied during vector search, not after (no more manual TOP_N hints needed), plus an optimizer that chooses between DiskANN and exact kNN on its own. Those changes did far more than any change of label to make the feature production-ready.

Section summary: GA arrives after the preview lost its worst restrictions. Read-only tables and post-filtering belong to the older index format, not the current one.

Why DiskANN, and why "approximate" matters​

Microsoft's documentation says that in the SQL Database Engine, vector indexes are based on the DiskANN algorithm. DiskANN relies on creating a graph to navigate quickly through all the indexed vectors to find the closest match to a given vector. Its main selling point is resource efficiency. Microsoft says it efficiently uses SSDs and minimal memory to handle significantly more data than in-memory indices, while maintaining high queries per second (QPS) and low latency. That matters on a transactional database where RAM is expensive and shared with everything else.

"Approximate" is a real trade-off. An exact k-nearest neighbor search compares the query against every row, and Microsoft notes that k-NN queries often struggle with scalability, making it acceptable in many cases to trade off some accuracy, particularly recall, for significant speed gains. Recall is the share of the true nearest neighbours that the index actually returns, and a recall of 1 means no approximation at all. Microsoft argues the trade-off is reasonable for AI workloads because embeddings are already approximations of meaning.

Microsoft also offers a rule of thumb: exact search is generally recommended when you're searching fewer than 50,000 vectors. The table can hold many more, as long as your WHERE clause narrows the candidate set to that size or less. If you need guaranteed exact ranking, such as for compliance or deduplication, VECTOR_DISTANCE with ORDER BY is still the right tool.

DiskANN isn't unique to Azure SQL. Microsoft describes it as developed by Microsoft Research and used extensively at Microsoft in global services such as Bing and Microsoft 365, and the same algorithm is also used in Azure Database for PostgreSQL.

The syntax you'll actually write​

According to the CREATE VECTOR INDEX reference, a basic index looks like this:

CREATE VECTOR INDEX vec_idx
ON dbo.wikipedia_articles (title_vector)
WITH (METRIC = 'cosine', TYPE = 'DiskANN');

The supported metrics are cosine, euclidean and dot (the negative dot product). DiskANN is the only index type, and it's the default. You can use MAXDOP to limit parallelism during the index build and ON <filegroup> to control where the index is stored. Creating an index requires ALTER permission on the table.

With the current index format, a search query uses SELECT TOP (N) WITH APPROXIMATE:

DECLARE @qv VECTOR(1536) = AI_GENERATE_EMBEDDINGS(N'wireless headphones' USE MODEL EmbeddingModel);

SELECT TOP (10) WITH APPROXIMATE p.name, p.price, vs.distance
FROM products p
INNER JOIN VECTOR_SEARCH(
    TABLE = product_embeddings AS e,
    COLUMN = embedding,
    SIMILAR_TO = @qv,
    METRIC = 'cosine'
) AS vs ON p.id = e.product_id
WHERE e.category = 'Electronics'
ORDER BY vs.distance;

Watch out for older samples. Many blog posts, and even Microsoft's own overview page, still use the TOP_N argument inside VECTOR_SEARCH. That argument belongs to the older index format. If you run it against a version 3 index, the engine returns error Msg 42274. The fix is to remove TOP_N and use SELECT TOP (N) WITH APPROXIMATE instead.

The documentation also suggests adding ordinary B-tree indexes on the columns you filter by, such as category in the example above. The optimizer can then use both index types during iterative filtering. If you need to force the ANN path, there's a FORCE_ANN_ONLY table hint.

Limitations to check before production​

Microsoft Learn documents the following constraints. When we checked, they applied to the current index version as well:

1. At least 100 rows with non-NULL vectors must exist before you create an index. Otherwise creation fails with error Msg 42266.
2. The table needs a clustered primary key on an int column.
3. Vector indexes can't be partitioned.
4. Vector indexes aren't replicated to subscribers.
5. TRUNCATE TABLE is blocked. To clear the table, drop the index, truncate, reload at least 100 rows, then recreate the index.
6. DacPac and BACPAC deployments fail with vector indexes present, because the import creates schema, including the index, before it loads any data. Drop the indexes before export and recreate them after import. This one will catch out CI/CD pipelines.

Microsoft also advises deduplicating embeddings before indexing, because repeated vectors crowd out useful results. If you re-embed most of a dataset with a new model, drop and recreate the index afterwards so that recall and ranking stay predictable.

Migrating preview-era indexes​

If you tried the preview early, your indexes may use the older format, which is deprecated and will be retired in a future version. You can check with this query:

SELECT i.name AS index_name, t.name AS table_name,
       JSON_VALUE(v.build_parameters, '$.Version') AS index_version
FROM sys.vector_indexes AS v
JOIN sys.indexes AS i ON v.object_id = i.object_id AND v.index_id = i.index_id
JOIN sys.tables AS t ON v.object_id = t.object_id;

A value of 3 means the current format. Anything lower can't be upgraded in place: you have to drop the index (DROP INDEX) and recreate it (CREATE VECTOR INDEX), which uses the latest format automatically. Approximate search on that table stops working from the moment you drop the index until the new one is built, so do this in a maintenance window. You can monitor background index maintenance through sys.dm_db_vector_indexes.

During the rollout of the new format, the Azure SQL team suggested a quick check for whether a database had received it: SELECT OBJECT_ID('sys.dm_db_vector_indexes') AS new_dmv_available; If this returns NULL, your region hasn't received the deployment yet. That check comes from the preview period, but it's still a quick sanity test if you run into unexpected syntax errors.

Documentation vs. announcement​

When we checked, the CREATE VECTOR INDEX and VECTOR_SEARCH reference pages were still titled "(Preview)". The overview page still said approximate vector index and vector search are in preview and currently only available in SQL Server 2025 (17.x), Azure SQL Database, and SQL database in Microsoft Fabric. Those pages were last updated in March 2026, so they most likely just haven't caught up with the announcement. Documentation often trails launches.

The practical takeaway is to treat the GA announcement as the authority on status. Keep the documented limitations in your plans until Microsoft publishes updated post-GA documentation that says otherwise. Earlier rollout notes also warned that deployments are happening worldwide, and availability may vary by region. The GA notice doesn't list regions, pricing changes, SLA terms or tier-specific details, so check your target region before you commit.

Keep the scope tight, too. The announcement names Azure SQL Database. SQL database in Fabric shares the same engine features. SQL Server 2025 still requires the PREVIEW_FEATURES database-scoped configuration to be turned on, and the latest index version is currently available only in Azure SQL Database and Fabric SQL. Nothing we found confirms GA status for Azure SQL Managed Instance.

Is Azure SQL now a vector database?​

For many line-of-business apps, it's close enough. If your customer records, tickets or product catalogue already live in Azure SQL, you no longer need to sync that data to a separate vector store. That means fewer ETL jobs, one security model, and joins that treat semantic similarity as just another predicate. Microsoft made the same argument at the preview launch, saying teams often had to stitch together separate vector databases and ETL pipelines, adding complexity and cost.

It isn't the answer for everything. Workloads with billions of vectors, heavy full-text and vector hybrid ranking, or search traffic you want isolated from OLTP may still suit Azure AI Search or a dedicated vector engine better. The constraints above, including the integer primary key, no partitioning and no replication, will also rule out some existing schemas. Our view, based on general industry practice rather than published benchmarks: run a pilot on representative data, measure recall against an exact kNN baseline, and only then pull out any sync pipelines.

Bottom line: GA means Azure SQL Database users can run indexed semantic search in production using plain T-SQL. Before you do, move any preview-era indexes to the version 3 format, update scripts that still use TOP_N, and plan around the documented limitations.