SQL Server 2025 adds native support for vector data and vector search. Applications can keep embeddings alongside relational data and use the SQL Database Engine to find semantically similar information.
A small proof of concept is easy enough to build: store an embedding, calculate the distance between vectors and return similar records.
The questions I find more relevant begin when vector data becomes part of a production workload. It then has to fit into the same operational environment as the rest of the database, including capacity planning, performance testing, security, recovery and ongoing support.
At that stage, I want to know how the workload behaves in the environment where it will actually run. A working vector search alone does not answer that.
SQL Server vector search can simplify an architecture
Native vector support allows relational data and vector data to stay in the same database platform.
Microsoft describes the SQL Database Engine as an option for scenarios where applications need to search structured, unstructured and vector data together. If an application already relies heavily on SQL Server, keeping that workload in the same platform may avoid the need for a separate search service.
The additional workload still has to run somewhere. In this design, it runs inside SQL Server, shares the same underlying resources and becomes part of the same operational responsibilities.
Before choosing this architecture, I would want to understand what the vector workload adds to the existing database environment and whether the simplification at application level creates new pressure elsewhere.
Microsoft: Vector search and vector indexes in the SQL Database Engine
Vector data has a measurable database footprint
SQL Server stores vector values in an optimized binary format. With the default float32 representation, each dimension requires four bytes.
A 1,536-dimensional vector uses 6,144 bytes, roughly 6 KB, for the vector values alone. The rest of the row and the surrounding database structures come on top of that.
In a small test database, that number is easy to overlook. With hundreds of thousands or millions of rows, vector data can become a noticeable part of the database footprint.
Vector dimensions, row counts and expected growth therefore belong in normal capacity planning. A proof of concept with a few thousand rows tells us very little about how much space the same design may require later.
The embedding model matters as well because different models use different vector dimensions. A choice made in the application or AI layer can have a direct effect on database size.
Microsoft: Vector data type in SQL Server
Vector search needs realistic production testing
Storage is only part of the workload. Search behavior also needs to be tested with realistic data volumes.
Exact vector search calculates the distance between a query vector and the candidate vectors before returning the closest matches. As the number of candidates grows, SQL Server has more work to do.
Microsoft gives fewer than 50,000 vectors as a general recommendation for exact search. A table itself can contain considerably more data if other predicates reduce the number of vectors involved in the actual search.
The total table size therefore tells only part of the story. I also need to know how many vectors a particular query evaluates and how those searches behave alongside the existing workload.
For a production-oriented test, I would measure execution time, CPU consumption and I/O with representative data volumes. I would then repeat the same tests while the rest of the application is active, because that is much closer to the environment the database will have to handle later.
A fast search against a small dataset can be useful during development. It says little about how the same design will behave after months of data growth.
Feature maturity becomes part of the architecture decision
For larger search sets, teams may eventually consider approximate search instead of evaluating every candidate vector.
SQL Server 2025 includes approximate vector search and vector indexes for this scenario. Approximate search trades some exactness for better scalability and lower resource requirements.
At the time of writing, approximate vector search and vector indexes are still Preview features in SQL Server 2025.
I would not reject a feature simply because it carries a Preview label. I would, however, treat that dependency differently when evaluating a business-critical workload.
The first question is whether the application needs that functionality at all. If it does, I also want to know what the fallback looks like if the planned implementation cannot be used as expected.
The current vector implementation has other limitations that can affect an existing database design. Always Encrypted does not support the vector data type, and SQL Server does not allow vector columns as keys in traditional B-tree or columnstore indexes.
For some applications, those limitations will have little practical effect. For others, they may conflict directly with an existing security or indexing design. That has to be checked against the actual environment.
Production readiness is about the whole service
Once an application depends on embeddings and vector search, the operational model has to cover them as well.
The security model still has to match the data the application stores. Access paths, permissions and data classification remain part of the same database design, even when some of the stored values are vectors.
Recovery deserves the same attention. Restoring the database successfully is one technical step. The application also has to work with the restored data and provide the vector search functionality it depended on before the failure.
Much of this is familiar DBA work. SQL Server 2025 introduces another type of workload, but sizing it, measuring its behavior and understanding its dependencies are familiar operational tasks.
For a production decision, I would want evidence from the environment where the workload is expected to run: representative data volumes, realistic concurrent activity, understood feature dependencies and a recovery test that includes the application behavior. A successful demo would be the beginning of that evaluation, not the result.
Foto von TECNIC Bioprocess Solutions auf Unsplash
