Remember when we announced the Public Preview of DiskANN vector indexes back in November and mentioned that once you created the index, your table became read‑only? Yeah… about that… 😅 We shipped early because the demand for Vector search in SQL was overwhelming. We knew the constraints weren’t ideal, but we also knew the fastest way to get this into your hands was to iterate in public.

You gave us feedback. Lots of it! And today, we’re excited to say: those major preview limitations are gone. We are happy to announce that the DiskANN Vector Index public preview just received a major upgrade, removing the initial constraints and unlocking high‑performance vector search at scale without sacrificing day‑to‑day operations.

What’s New

Pretty much all the major limitations are gone:

• Full DML support – Tables are no longer read‑only after index creation
• Iterative filtering – Filters are applied during vector search, not after (no more manual TOP_N hints needed)
• Smarter optimizer – Automatically chooses between DiskANN and exact KNN
• Improved quantization – Faster builds and better search quality

Availability

As announced today at SQLCon, these improvements are rolling out across Azure SQL Database and SQL database in Microsoft Fabric. Deployments are happening worldwide, and availability may vary by region. Check the documentation for availability in your region. Run this quick check to see if your region has the new version:

-- Check if the new DMV exists
SELECT OBJECT_ID('sys.dm_db_vector_indexes') AS new_dmv_available;

If this returns NULL, your region hasn’t received the deployment yet. Check back in a few days! If instead it returns a number, you’re good to go!

Creating Vector Indexes (No Changes!)

Good news: the syntax hasn’t changed. Any vector index you create now automatically uses the latest version

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

What has changed is what happens under the hood: index creation is now significantly faster, thanks to Optimized graph construction, improved parallelization, and a new quantization approach. Build time still depends on your data size and service tier, but for large datasets especially millions of rows you should notice a big difference. This comes at the cost of slightly larger index files on disk, a tradeoff that works well for most deployments. No configuration changes required.

Migrating Existing Indexes (Read carefully)

If you created DiskANN indexes during the November preview, they use an older data structure. To get the new capabilities, you’ll need to drop and recreate them.

⚠️ IMPORTANT: Query syntax changes after migration

The new index version uses improved syntax that removes previous limitations. The TOP_N parameter is no longer supported in favor of the new SELECT TOP (N) WITH APPROXIMATE syntax

Before migrating, update your application code to use the new syntax. If you migrate the index without updating your queries, vector searches will fail as the new index does not support the explicit TOP_N parameter.

For detailed Migration Guidance check the documentation here .

With migration and query updates out of the way, the most important change becomes immediately visible.

Full DML Support 

This is the big one! Tables with vector indexes are no longer read-only. You can freely insert, update, delete, and merge rows without dropping the index or enabling special configurations like ALLOW_STALE_VECTOR_INDEX.

--For example we delete a row
DELETE FROM dbo.wikipedia_articles WHERE id = 9999;

-- Run a vector search immediately - the deleted row won't appear
SELECT TOP (10) WITH APPROXIMATE
    t.id, t.title, s.distance
FROM VECTOR_SEARCH(
    TABLE = wikipedia_articles AS t,
    COLUMN = title_vector,
    SIMILAR_TO = @query_vector,
    METRIC = 'cosine'
) AS s
ORDER BY s.distance;

The deleted row is immediately invisible to queries. The background maintenance handles cleanup asynchronously.

Observing Background Maintenance

Full DML support works because DiskANN indexes are maintained asynchronously.

• When you insert, update, or delete rows, your transaction commits without waiting for the index to update. The DML operation isn’t blocked by index maintenance, and those changes are visible to vector search queries right away.
• In the background, the system queues the updates and gradually incorporates them into the DiskANN graph structure. Your application keeps running, queries keep executing, and the index optimizes itself without requiring you to pause writes or rebuild indexes.

This asynchronous design is what makes operational RAG possible in SQL: Live data, continuous ingestion, and Vector search that stays online.

If you’re curious to observe this process, you can peek under the hood using the sys.dm_db_vector_indexes DMV:

SELECT 
    OBJECT_NAME(object_id) AS table_name,
    approximate_staleness_percent,
    last_background_task_succeeded,
FROM sys.dm_db_vector_indexes;

approximate_staleness_percent indicates the proportion of recent changes that have not yet been fully incorporated into the DiskANN graph. Because index maintenance is asynchronous, this value typically fluctuates over time, especially in workloads with continuous inserts or updates. There is nothing you need to tune or manage as the system handles it automatically

Even when staleness is non‑zero, recently inserted or updated rows remain queryable. Search esults may be slightly less optimal in terms of recall until those changes are fully integrated, but rows are not omitted from query results.

Query Syntax and Iterative Filtering

This update introduces a new query syntax and a more efficient way to apply filters during vector search. Vector search now uses: TOP (N) WITH APPROXIMATE

• By specifying WITH APPROXIMATE, you’re indicating that approximate results are acceptable.
• The optimizer then decides whether to use the DiskANN index or exact KNN based on data size, predicates, and cost.

With Iterative Filtering filters are no longer applied after the vector search completes. Instead, predicates are evaluated during the search itself. This removes the need to over‑fetch vectors and ensures you get the number of results you ask for.

Here’s a quick look side by side to see the difference clearly:

SELECT TOP (20) t.id, t.title, s.distance
FROM VECTOR_SEARCH(
    TABLE = wikipedia_articles,
    COLUMN = title_vector,
    SIMILAR_TO = @query_vector,
    METRIC = 'cosine',
    TOP_N = 20  -- Over-fetch!
) AS s
WHERE category = 'Technology'
ORDER BY s.distance;

SELECT TOP (10) WITH APPROXIMATE
    t.id, t.title, s.distance
FROM VECTOR_SEARCH(
    TABLE = wikipedia_articles AS t,
    COLUMN = title_vector,
    SIMILAR_TO = @query_vector,
    METRIC = 'cosine'
) AS s
WHERE t.category = 'Technology'
ORDER BY s.distance;

Query Optimizer at work

Here’s the power of this approach, As your application grows, the Exact same VECTOR_SEARCH query continues to work while the optimizer adjusts the execution strategy for you:

Try It Yourself

We have put together a simple Quick Start script that demonstrates all these new capabilities in action. The sample uses Wikipedia article embeddings for semantic search and can be found on our Github repo DiskANN Vector Search Quickstart.

What’s Next

These improvements make DiskANN much more practical for production RAG scenarios. While this is still a public preview with some limitations, the major blockers are now resolved.

For comprehensive documentation and up-to-date information on current capabilities, see:

For complete documentation on DiskANN Vector indexes, including detailed syntax examples and current limitations, see:

• VECTOR_SEARCH (Transact-SQL)
• CREATE VECTOR INDEX (Transact-SQL)
• Understanding KNN and ANN

Give it a try and let us know what you think! As always, your feedback helps shape where we go next with Vector Search in SQL.