Building AI features has followed the same frustrating pattern for the past few years. Your operational data lives in SQL Server. Your AI workloads need a vector database. So you copy data across, write pipelines to keep everything synchronised, rebuild your access controls in the new system, and spend several months wondering why your retrieval results are inconsistent.
SQL Server 2025 changes that. Microsoft has embedded AI capabilities directly into the relational engine, which means your data stays where it is, your security model stays intact, and your developers work on a platform they already know.
This blog covers what has actually changed in SQL Server 2025, what it means for both business and technical audiences, and why it makes the upgrade case considerably stronger.
The problem with bolt-on AI infrastructure
Anyone who has tried to add semantic search or a retrieval-augmented generation (RAG) system to a production application knows the friction. Transactional data sits in SQL Server. Vector databases live elsewhere. Getting them to talk requires ETL pipelines, synchronisation logic, and a separate permissions model to build and maintain indefinitely.
The engineering overhead is significant. Synchronisation lag creates inconsistencies between what your application knows and what the AI sees. Schema changes ripple across multiple systems. Security work done once in SQL Server has to be replicated from scratch in every additional data store you introduce.
SQL Server 2025 removes most of that complexity by making the relational engine also a capable AI engine.
.
Native vector storage and the DiskANN index
The headline addition in SQL Server 2025 is a native VECTOR data type with built-in embedding support. Rather than sending data to an external vector store, SQL Server stores and searches vectors natively, in the same engine running your transactions.
The indexing technology is DiskANN, short for Disk-based Approximate Nearest Neighbour. Most vector indexes - HNSW being the common alternative - keep the entire vector graph in RAM. At scale, that is expensive hardware. DiskANN compresses vectors into compact, byte-sized IDs using Product Quantisation for in-memory graph traversal and only fetches full vectors from SSD for the final distance-ranking step. The result is high-recall vector search at a fraction of the RAM cost.
Queries use the VECTOR_DISTANCE function alongside standard T-SQL, so this integrates into existing query patterns rather than requiring a new query language. For teams building RAG systems or intelligent agents, the simplification is material: one fewer infrastructure component, no synchronisation layer, and no separate backup and recovery regime to maintain.
Search that understands what people mean
A practical example that shows why this matters. A customer searches your website for "lightweight bike for racing." Your product catalogue lists the item as an "aerodynamic road bicycle." Traditional keyword search returns nothing - it only matches on exact terms.
SQL Server 2025's semantic search works on meaning rather than text. It understands that "lightweight for racing" and "aerodynamic road" describe the same thing. It also works across languages, so a query entered in French can surface a product described in English without a translation layer sitting in between.
Technical note: semantic search uses VECTOR_DISTANCE against stored embeddings. Embeddings can be generated via built-in model integrations or passed in from an external model endpoint. Both approaches sit inside standard T-SQL.
Hybrid search: AI relevance with business rules enforced
Semantic search on its own creates a different problem. If a customer searches for "comfortable trail bike under £500," the AI might surface a product that is conceptually perfect and costs £900, currently out of stock. Pure semantic relevance has no concept of the constraints your business actually runs on.
Hybrid search in SQL Server 2025 addresses this. The query optimiser applies standard relational filters first, using existing B-tree indexes, before running the computationally heavier vector distance calculations on the remaining candidate rows. Price ceiling, stock status, region, account tier - whatever constraints apply - are enforced before the AI evaluates anything.
This has applications well beyond e-commerce. Financial records restricted by client entity, medical data restricted by patient, and support cases restricted by assigned team can all use the same pattern: exact relational accuracy first, followed by semantic relevance across the qualifying rows.
Security that carries across automatically
One of the more practically important aspects of SQL Server 2025: when AI features are enabled, they inherit your existing security model rather than requiring a parallel one to be built alongside it.
Row-Level Security, Dynamic Data Masking and Entra ID integration all apply to vector queries automatically. If an employee cannot access sensitive payroll rows through a standard application, they will not reach those rows through an AI query either. There is no separate permissions layer to build, test and audit.
AI features are disabled by default. Your IT team decides when they are switched on and for which workloads. For organisations in regulated industries or with strict data governance requirements, that default-off posture matters - it keeps your attack surface clean until you choose to expand it.
What is new for development teams
Beyond the AI capabilities, SQL Server 2025 ships several engine upgrades relevant to general development work.
JSON now uses native binary storage with a capacity up to 2GB, with new operators including .modify and aggregation functions like JSON_OBJECTAGG. If you have been storing large JSON documents as raw text and hitting I/O issues, the difference is noticeable.
The engine adds built-in support for calling REST and GraphQL APIs directly from SQL, alongside native change event streaming. Both reduce the custom middleware needed to connect SQL Server to a modern application stack.
Optimised Locking and tempdb space governance address a concern that surfaces when AI workloads run alongside transactional processing: ensuring the two do not compete destructively for resources. The performance isolation means you do not have to choose between them or provision entirely separate environments.
What this means for your SQL Server
For organisations still on SQL Server 2016, 2017 or 2019, the upgrade case has historically been about security patching, lifecycle supportability and incremental performance gains. SQL Server 2025 adds a commercially significant reason: the ability to build AI-powered applications on your existing data estate, without standing up separate infrastructure or rebuilding your security model.
That said, the upgrade still needs to be done carefully. Data estate assessment, compatibility testing, migration sequencing and performance validation are not optional steps. They are what determines whether you actually extract the benefit rather than just inheriting new complexity.
At DSP, we work with organisations across regulated and data-intensive industries to plan and execute SQL Server modernisation. Whether that is an in-place upgrade, a move to SQL Server on Azure, or a broader data platform review, the aim is the same: getting your data into a position where it can do more for the business, reliably and securely.
You can find out more about all the available options on our website or contact us today to discuss your SQL Server modernisation plan. Let's work together to ensure your database is secure, compliant and future-proof.
.png?width=250&name=stonewater-logo%20(1).png)
