48:56 Webinar
The Future of Intelligent Data Platforms: AI-Powered Search in SQL Server 2025
Semantic search allows applications to find relevant information based on meaning, rather than exact words. In this session, we'll look at how SQL Server 2025 implements this technology using native vector support and demonstrate how it can be used to build intelligent search experiences.
This webinar first aired on 23 July 2026
The first 5 minute(s) of our recorded Webinars are open; however, if you are enjoying them, we’ll ask for a little information to finish watching.
Click to View Transcript
Hello. Good morning, good afternoon, good evening, wherever you're based. Welcome to this session, AI-Powered Search in SQL Server 2025. Excellent. Just to introduce ourselves, Dave, would you like to introduce yourself first?
Yes, certainly. Yeah, good afternoon, good evening, good morning, everybody. My name's Dave Ruddle. I'm an enterprise systems engineer in, within the sales organization at Everpure. Been in the company about seven years now, so, yeah, a lot of experience working with customers running, Enterprise SQL database and applications.
Fantastic. And my name is Andrew Prosky. I'm a principal field solutions architect here at Everpure, specializing in SQL Server. Joined in September 2022, and before that, I was a SQL Server DBA for around 15 years. From originally Swansea, Wales, but now based in Ireland. Next slide, please. Before we jump into the session, just a couple
of quick things to mention. We c- starting on the 8th of September to October 24th, we have the Pure Accelerate Global Roadshow. So if you wanna discover how efficiency, predictability, and actionable data can help your organization move faster and stay ready for what's next, register now.
Click the, sorry, scan the QR code there and find It really is a global roadshow. We have cities, events in London, Melbourne, Mumbai, Munich, Paris, Singapore, Tokyo. So scan the QR code there and find one that's closest to you. And then the second thing on the slide on the right is if you wanna get involved and connect with your peers or Everpure experts, get involved with our communities and scan that QR
code there. Okay. So let's dive into this AI-powered search in SQL Server 2025. Now, I know I've already introduced myself. I just want to highlight a couple of things on this slide. My contact details are there, so if you have any questions after today, please feel free to
reach out. I'm always willing to talk about this stuff. And the last one there is my GitHub account. All the slides and the code for the demos, 'cause it's a very demo-heavy session, are available in a repo in my GitHub, and we will be posting a link to that at the end. And that repo contains a whole bunch of resources all related to AI-powered search in
SQL Server. All the links and all the websites that we'll be having a look at during the demos are there available for you as well. So onto this session. What are we gonna be doing today? Well, we're gonna be diving into exactly how AI-powered search works in SQL Server 2025.
Starting from the ground up, we're literally gonna build a database, import some data, and start running some AI-powered searches over that data. We're gonna build an AI-powered search tool to provide burrito recommendations in Ireland. Now, I appreciate bit of a weird use case, but stay with me. There's method to my madness.
So I've had a couple of iterations of this, and the first one I built looked like this, and I was doing things like give me a restaurant in Temple Bar in Dublin, or give me a restaurant that has greater than a four-star recommendation on Google reviews. But I realized I was being a bit silly. If we do things like this, Dublin, four star, these are keyword searches.
SQL's been able to do this, well, forever. This is exactly SQL's bread and butter. This is what SQL was designed to do. However, what about something like this? Find me a restaurant with a cozy atmosphere.
What if we could capture the meaning of that data and then query over it? So we're not doing exact keyword searches here, we're doing semantic similarity searching. And so this is what I ended up with, and this is the final well, with a few tweaks. Find me a restaurant with authentic Mexican food. So we could do keyword searches on authentic Mexican food, but what about capturing the
meaning of that query and comparing it to meaning already captured in our database? And so that's what semantic similarity searching is, this AI-powered search that we have in SQL Server 2025. It finds results with similar meaning, even though the exact words may differ by comparing vector embeddings generated from data.
Okay, fine, but how do we store meaning in a database? I've mentioned it a couple times already. Embeddings. Embeddings capture the meaning of data and represent them as numerical vectors in a multidimensional space. And in that multidimensional space, similar concepts are positioned closer together,
and we can measure the distance between them using different metrics. However close they are means how much the similarity they have between them. In SQL Server, we store embeddings using this new data type available to us, called the vector data type. We have a look at it. It's stored in a optimized binary format, but
it's displayed as an array of floating point numbers. And we have float thirty-two, which is the default, and float sixteen data type supported. And you can see the example there. I have a float thirty-two in my embeddings column with a size of one thousand five hundred and thirty-six.
Now, that size is dictated by the external model that I'm using. What we're doing is taking data from our database, sending it to a model, and it generates the embeddings from that data, and the size of the array of float point numbers brought back is dictated by that model. Now, you can overwrite it, but for this purposes, for the purposes of this demo, we're
gonna keep the default. So, okay. We've briefly covered this stuff, and what I mean briefly, because I want us to go into the demos and start building this out. So what are we going to do?
We are going to get some raw data. We're going to create a reference to an AI model that we can hit from our database to generate our embeddings. And then we can search that data, and there's two different types of searches within SQL Server available to us via new functions, and we'll have a look at both of those coming up.
So this is the raw data that I started with. So we've got things like name, rating, review count, address, but this is what I'm gonna refer to from now on as the metadata of the restaurants because, okay, SQL can que- we could drop all this into a table, probably multiple tables if we wanted to do it properly, and do searches over it, but those would be keyword searches.
Find me a restaurant in Dublin, find me a restaurant with a rating greater than four, things like that. But what about using review data of the database, or of, of the databases, of the restaurants recorded on Google Maps? What if we could capture the meaning represented in this review, in these reviews, and then perform searches over the top of and pull out restaurants from those review datas
compared to whatever query we're putting in? One other thing before we actually dive into the demos, something called chunking. Those reviews, if we have a quick look at it, okay, they could be fairly lengthy. Now, do we want to just send the entire review to the model, let it generate the embedding over that, or do we want to chop it up?
Now, if we have a large amount of data sending off, that embedding could become vague. It could kind of lose its meaning a little bit. However, if we chop it up, we could have loss of context between the chunks. And of course, if we have more chunks to send to the model, that's more computationally expensive.
We're burning through more CPUs, more tokens on the AI model, and we'd have to factor that in as well. So there's a load of design considerations here when it comes to how we send our data over to our model. However, as you'll see in the demos coming up, we're just gonna take the entire review and slap it over to the model, bring that embedding data back.
So how do we generate those embeddings? Well, I mentioned it. We have the data in the database. We've pulled it down from somewhere. I actually used PowerShell to hit, Google Places API and pulled review data down for various different restaurants across cities in Ireland, Dublin, Belfast, I think I did
Waterford, Limerick, Cork, et cetera. Once we have that data, we then need to create a reference to an AMI an AI model before we send it, before we generate those embeddings. So we do this through T-SQL. We say create tech- create external model, give it a name, and then we specify a location
where we can hit the API format, the model type, the model name, and a credential where we store our API key so that we can authenticate against that model. And then once we have that model, we can reference it in a new function called AI generate embeddings, the text we want to generate the embedding from in that variable @text, and then just referencing the model that we've created.
Okay. So no further ado, let's jump into the demos, and let's have a look at how we can get this set up. So we're up in my lab. This is up in Azure, and I'm going to use a model in the Azure Foundry. Now, of course, you don't have to use Azure Foundry models.
You can use local models as well, and there's a link that for, to a blog that was written by my counterpart over in America called Anthony RTOsentino, who will take you through using an Llama model locally with a SQL instance to generate your embeddings. But for this, we're gonna use a model up in Azure. But we're gonna start right from scratch here.
I've got a database here, but I'm actually gonna drop it. Let's get rid of it, and we'll recreate it. Now, this is a fairly standard database. We're just going one data file on the MDF, an archive, some data, and I'm separating, separating out my embeddings here.
I've, I've seen people build tables, and I'm putting the embeddings column on the end of that table, a new column, and then just drop them there. There are a couple of design things, and you'll see these coming up of why you shouldn't do that. Generally, I would recommend you keep your embeddings data separate.
So let's go ahead, and let's create that database. Excellent stuff, and it should be there now. Well, it was there before, but we've recreated it. There should be nothing in it. Fantastic. Okay. And just quickly to interrupt you.
Of course. You said about, storing the vector data separately from the data that it was generated from. Yeah. Would you put that in a separate table, um- For these purposes- And what, what would you do then? You can have them in a separate table, yes, one hundred percent. That's what we're gonna do here.
You can also use things like the new features in SQL Server twenty twenty-two and create a reference to an external table for data hosted on S3. So you can keep this data completely separate from your live production database if you wanted to because we've done some testing here, and it can significantly increase the size of your database. It's highly unique data, and there's a, a
large array coming through, and if you have, we're only dealing with, like, two hundred and twenty-nine rows here 'cause it's a simple demo, but typically when we're talking about AI data, we're talking, what, hundreds, thousands, millions, billions of rows. So this could get very big very quickly. So using features like that external model, external table model could be very beneficial.
However, we've also done some testing on our Pure FlashArrays and seeing how our data du- data reduce works. Da- sorry, data deduplication works. And for, okay, it's highly unique data, so, most deduplication things will struggle at, but we're still getting about a two-to-one data reduction ratio on a FlashArray, so still
pretty good. Not as great as what we usually get for SQL Server normal data, four to one, but still two to one, still reducing the data imprint of your embeddings data by fifty percent is nothing to be sniffed at. Cool. All righty. Let's go ahead, and let's create a bunch of schemas, and let's create some tables.
So I've got some main tables to hold my data. Um- Just place ID. This is the metadata of the table. And then we're gonna have some review data here as well. So two tables linked together by a foreign key.
And, just to point out, I'm using a bit of an odd collation here. The reason for this is that review data contains emojis, and I wanted to preserve them throughout this whole process. So that's why I'm changing the collation there. So let's go ahead, and then we've got some embedding data here.
Restaurant review embeddings, embeddings column, and I'm gonna go with one five three six, size float thirty-two for my vector data type. Now, that is dictated by the model. And to find that out, you go and investigate. The model will tell you in the Azure Foundry, or there's a website called the Massive Text,
Embedding Benchmarks, which will give you even more information and actually performance reviews of each model, and we'll have a look at that in a sec. But let's create these tables. Oh, what did we have a problem with there? Oh, did I already create those? That's all it is. Cool. So I went and created the schemas
originally, but we've got our tables there. Excellent. One, two, and three. Excellent. Okay. Next one. Now, we're gonna create some raw data tables to hold What I'm going to do is I've already pulled down all the review data into CSVs
locally on this machine, and we're gonna import them into these tables before we do anything, and like splitting up the data out and getting them into the restaurants and the reviews. The reason I'm doing this is purely so that when I was working with this data, I was separating out the raw data to, say, the normalized data before we go ahead and
generate our embeddings. So three, two, one, let's create those. Excellent. And there we go. And I've split them out by city as well. So you've got Belfast, Cork, Dublin, Galway, Limerick, Waterford.
Probably a little bit over the top. We could probably just do Ireland. There's only two hundred and twenty-nine of them, eventually here. But keeping it separate so I can work on them separately. That's just the reason for my methods here.
Okay. So let's import that raw data. As I said, I've already pulled the raw data down, CSVs via split out by city. Now, these CSVs are included in the GitHub repo. So you don't need to go and find your own data.
So if you want to go and build this out yourself, all you'll need is an instance of SQL Server twenty twenty-five and access to a model and this repo. These scripts are designed that you can just run them, pull it Sorry, pull the repo down, open the script and run them. You may have to change obviously the file path, but you should be good to go.
So three, two, one, let's import that data. Excellent stuff. And then we're going to import it into the main tables. So just doing a little bit of a select from the raw data, and, and we're adding in this URL to the place ID. The reason I'm doing this for within the bot itself, that URL allows you to click on it,
and will take you to that restaurant's location in the, in the Google Maps. Here we go. There we go. Excellent stuff. Okay, so we've set everything up. We've imported our data. We can now create our model. And this is before we go ahead and create our embeddings.
So using the Burrito Bot DB, the first thing I'm gonna do is create a database master key in my database. And then I'm gonna create my Just pull this over a bit. My scoped credential where I'm gonna reference, just give it a name, and then I'm gonna reference my API key, which means I need to go and get my A- API key from Azure.
So if we come over, and up here we have the Azure Foundry, copy my key, and we can drop it back in. Three, two, one. Create the credential. Excellent. And then we can create the external model, and we've got the location, reference and the credential.
All the other information, if we come here and go into models, or sorry, deployments even. I've got two here. This one, text three embedding small for generate my embeddings, and this is where I grab all the information it'll give me on how to connect. So I've got my, target URI, my key, and then all the information if I want to drop it, say, into like Python scripts
and reference it that way. So let's create that model. We can view it within SQL Server itself via new DMV, sys.externalmodels. All my information there, model type, embeddings with the credential ID. Gonna make sure I've got this new feature enabled. This is the ability to use a store procedure to hit any external API endpoint from within
SQL Server twenty twenty-five. Brand-new feature of SQL Server twenty twenty-five, and it's basically how this new f- function, AI generate embeddings, works in the background. So we need to make sure we have that enabled before we can test generating embedding referencing our external model.
So I'm just going to see if this model works. I'm going to put some test text referencing my model, and we'll see if we get an embedding back. So three, two, one. Okay. If we click on that, as I said, these embeddings are then stored as an array of
floating point numbers. And if we scroll right to the bottom, yep, one three seven, 'cause we had the bracket at the top, size one five three six. Okay. So that is how simple it is to get up and running with this. We need some data, we need some tables to store that data, and we need the reference to an AI model.
But before we go any further, I talked about this high dimensional space, and I'll be honest with you, when I first started learning about all of this, new technology within SQL, this high dimensional space really sort of boggled my brain a little bit. It's a hard concept to get your head around. So I did a little bit of research And there is this website, this project.tensorflow.org,
which allows you to visualize embeddings. Now, it obviously scales the multi-dimensions down to three dimensions. But again, within that GitHub repo, if we want to, and I've got both here, we can load up our embeddings and some metadata all in TiB format. And we can actually visualize our embeddings within this sort of compressed
multi-dimensional space. If I stop spinning it, if I stop spinning it, there we go. We can see there are definite clumps there. There are certain ones which have similar concepts captured by these embeddings are clumped closer together. Now, this is the restaurant metadata.
So if we click on this one, we're looking at Belfast up here. If we come up here, we have Cork. And down here, Dublin. Okay, that's the restaurant metadata. Let's try it with the actual review data.
So we've got that in here as well. And we'll choose the metadata file. And here we go. Okay, less obvious this time, because it's review data, but there are definite ones clumped further together than the other ones. If we come here, we can have a look.
There we go. We've got a couple here. And if we look over on the corner here, we can see we've got distance metrics, cosine and Euclidean. We'll have a chat about These are just different metrics for calculating the distance between vectors within that high dimensional space.
And we have three available to us in SQL Server twenty twenty-five. So let's go ahead. Let's jump back into the slides, and we'll talk about some of the distance metrics we can use to compare our vectors in that multi-dimensional space. Okay. Before we go into the vectors, though, I wanna
talk about vector magnitude. Now, vector magnitude is actually calculated by the square root of the sum of the squared components of each of the individual vectors. But yeah, it doesn't really mean much to me. It's also calculated as the length of the vector.
But again, what does that mean? And again, this is another concept I found it really hard to get my head around. So let's take this statement, "I really love burritos," versus, "I really, really, really, really love burritos." Now, the magnitude of those two statements could be different because magnitude can vary due to wording, quantity,
emphasis, or just even the model behavior. And we need to make a decision of do we want that to affect our calculations when comparing vectors in that multi-dimensional space? Because essentially, really, if you think about it, those two statements have the same overall meaning. So when we're doing these semantic similarity
searches, do we want those two to be different, or do we wanna consider them the same overall? And we need to think about that when we use-- When we-- Sorry, when we pick a metric for comparing our vectors. So let's talk about the first one. The first one is Euclidean distance, which, is a scary formula, but it's scary to me anyway.
I'm not a mathematician. It's the square root of the sum of the squared differences between each of the individual A and B vector components. Now, what essentially we are doing, this is the simplest metric. We are measuring the straight line distance between two vectors in that multi-dimensional space.
However, because it's the straight line distance, it is sensitive to magnitude. So do we, again, do we want to have magnitude as a factor in our comparisons? Maybe not. So let's have a look at the next one. The next one is dot product, which is the sum of the product of each of the corresponding components of those vectors.
This measures the alignment of vectors. We can see that on the graph there. Again, though, this scales with magnitude. Length of the vector affects dot product. So do we want to take that into consideration when we're doing our searches?
For semantic similarity searching? Probably not. So then we have the final one, cosine similarity. Cosine similarity is just dot product divided by the product of the vector's magnitude. It takes magnitude out as a factor in the calculation.
And for that reason, maybe this is the one we'd wanna use when we are performing our calculations between two vectors in that high dimensional space. So in summary for the three, we have Euclidean distance. How far apart are these vectors in space? Dot product. How aligned are they factoring in magnitude?
And then cosine. How aligned are they ignoring magnitude? So why does cosine work for the Burrito Bot? Well, longer restaurant reviews really shouldn't make, Oh, sorry. Longer restaurant reviews shouldn't automatically rank higher.
We want reviews with similar meaning, not just more words. And that's why we use cosine, because it ignores the vector length, the magnitude, and compares the semantic direction, the alignment of the vectors. However, that all being said, let's throw a massive spanner in the works when it comes to picking a metric using certain models.
Certain models use what's, known as normalized vectors. These are vectors that are scaled, so their magnitude equals one. And in that case, because cosine is just dot product divided by the mag-- product of the magnitudes, one times one, one. Dot product then becomes equal to cosine.
And of course, I'm sorry, and of course, and weirdly, to me anyway, Euclidean distance produces the same ranked results as cosine and DOT products. Different numbers, but if we're just comparing, say, rankings, say we want the top 10 closest ones, and they all three, all three metrics produce the same rankings, then our choice of what metrics to use becomes
less of a factor. Okay, so we have got our metrics. We've picked one. If it's normalized, we could pick any one. We usually go with cosine. Let's start comparing vectors. So the first thing we do is exact search.
This is k-NN search. We're going to perform an exact search calculating the distance between our search vector and every other row in that table. That should have the DBAs on the call eyes perking up, going, "What do you mean every other row?" It selects the closest neighbor based on a specific metric.
It is computationally expensive because we're calculating distance between every other row in that table, and that does mean the dreaded table scan. We don't like table scans as DBAs. Let's have a look at how it actually works. So here we go.
We would say declare some search text, and we'd say something like, "Find me a restaurant with a great atmosphere." So capturing the meaning of that statement and comparing it to our review data, the meaning within our review data. We say @searchtext. Use our model. We then perform a search, and we use this
function here, the new function available to us within SQL Server 2025, which is vector distance. Specify a metric. Here we're using cosine. Our search vector and the embedding stored within our table, and that will perform our calculations for us.
Order by distance, and here is an example query plan that we would get back. And of course, as you can see here, we are doing scans of the table because vector distance will compute will work out the distance between the metric in the sorry, the embedding stored in the table and our query vector, our query embedding. So let's go ahead, and let's have a look at performing some searches using vector distance
in SQL Server 2025. If I come back to my Oops. Save. Open file. And we've got vector distance here. Okay. Now, the first thing was,
are my vectors normalized? Hopefully, your model will tell you if it doesn't. Excuse me. We actually have a new function within SQL Server 2025 that allows us, by using this and NORM2, to check to see whether or not the magnitude of our vectors is one.
Let's have a quick look at that. That's interesting. Did we not actually generate the embeddings? Did I miss that completely? I did. Okay, let's have a look.
All right. Okay, apologies, everyone. That's one script that I completely missed. Let's go ahead and actually generate our embeddings first. So we have our data here. We can chunk the data if we want to using AI generate chunks. Now, if we weren't going to send all the data
over to the model, we could chop it up a little bit, and we have our review text. Chunk size of six, how many characters we want in each chunk. And to try and prevent that loss of context that I was talking about earlier, we can have an overlap to try and preserve context between the chunks. So if we do that, we can go ahead and do that.
We can see here each review now has been chopped up. So we have the ability, if we want to, to chunk up our data if we have very large embedding sorry, a large amount of data that we want to generate the embeddings from. Okay, so let's go ahead, and now let's generate those embeddings. Let's actually do what I meant to do in the last demo at the end, but I got sidetracked
talking about, project visual the TensorFlow projec- projector and all that. So, okay, we have our function. I'm going to give, the model some context when it's generating embedding. I'm just gonna say this restaurant name is a Mexican restaurant in city. Customer reviews, say, and then I'm combining all the reviews for that restaurant.
I've got five per restaurant. Three, two, one. Let's go. Now, this can take up to a minute, so Dave, do we have any questions while we're waiting? By the way, I should've said at the start, if you have any questions, please do use the Q&A panel that's in the webinar there. Yeah.
So, there's a couple of questions. So the search can find you a restaurant in Dublin, can't it? A recommendation, not just a restaurant, but a recommendation based on what you're searching for. Now, this is the interesting one. Now, we'll have a look at that, actually, because we've captured the meaning of data,
and we're not searching on any keywords here. So if I ask it, and we'll we can have a check that when we get the embeddings back. But if I say, "Give me a restaurant in Dublin," it may be give us some restaurants back, but it could also pull out some restaurants that aren't there, that aren't in Dublin.
It could pull out reviews from Cork or Belfast because it's trying to capture the meaning of the data. If we wanted to, say, have a l If we had a really large data set and we wanted to narrow it down to, say, specific locations, we'd have end up with some sort of hybrid query search where we could use the restaurant metadata to filter out all the restaurants by Dublin and then perform the semantic similarity search
over the embeddings data there. So kind of a mix. And I think that's where we generally go with this type of stuff, is that hybrid search, using traditional keyword searching in, in SQL Server and then perform the similarity search. Cool. Cool. So that's finished. do we have Did we
have another question? Should we do that first? No, no more. Okay, cool. All right. So we have our data. And here we go at the end, we now have our embeddings, and we click on one of those, and yes, of course, it's down at one five three six, the length of the model.
So, okay, let's get rid of that, and let's go back to where we were at the start, vector distance. Okay. Are those vectors normalized? Let's have a look. Three, two, one. There we go. Now, we've got some rounding errors here
because of the floating point numbers, but those all look pretty close to one to me. So I would say that the vectors that I am getting back from this model are normalized. Therefore, okay, I could use dot product, cosine, they will give me the same results, and Euclidean distance will give me the s- the same ranked results as well. So let's perform an exact search using vector distance, using cosine distance.
Now, I should have said that in the slides, we talked about cosine similarity, where SQL Server uses cosine distance. Now, the difference between cosine similarity and cosine distance is cosine distance equals one minus cosine similarity. That's the, the only difference here.
And the reason SQL uses that is because we're not comparing how similar they are, we are comparing how far apart they are in that multidimensional space. So let's see this. Let's find me a restaurant with a good atmosphere, and let's have a look at what we get back. We do select top one, ranked by distance, three, two, one, and we get Texas Steakhouse
in Limerick. Okay. Why did it pick that one? So let's have a look at the review data and see if we can work out why it decided to bring that restaurant back. Let's have a look. Okay.
There we go. I'm pretty certain there is the atmosphere was fab. Okay. It's had a look. Oh, we've got another one there. Restaurant, well-presented, spacious, and a nice atmosphere. So, okay, we could have keyword searched on
atmosphere, but it's captured the meaning of those reviews there. We've asked for a good atmosphere. Those two are the most similar. It's brought this restaurant back. Let's do another one. Let's see if we can find a restaurant with authentic Mexican food.
Again, using cosine, top one, and I'll include the actual execution plan here. Three, two, one. Okay. We've got Salsa, authentic Mexican food in Dublin. If you have a look at that execution plan, there we go. We can see it's comparing all the rows of the table, doing that clustered index
scan on both tables that we've got. So need to be aware there. Okay. We've got two hundred and twenty-nine rows in this table. Doesn't really matter. As I said, though, when we're working with AI data, it's usually hundreds of thousands,
millions, billions of rows, so we wanna take that into consideration. Let's have a look at why it picked up that one. Let's have a look. Authentic Mexican food. There we go. Oh, really good, authentic tacos. Okay. True value.
I ordered a few times. Okay. Really vegetative. Love the place, cozy and music. Really good price. Okay, not bad. Quality of food, quality of food is spectacular.
Really authentic tacos. All right. We've got a negative review in there, but remember, we're only looking for one, and that's why it pulled out that data here. So again, it captured the meaning of that, those reviews, compared it to the query, and this is the one it's come back with.
That's the most similar to our query vector. Okay. Right. I'm gonna jump back into the slides because now I wanna talk about the other type of search that we have available to us in SQL Server twenty twenty-five. That is vector search.
Not vector distance, vector search. And this requires an index to perform what's known as a approximate search because the exact KNN search does not scale for large vector data sets because we are scanning that entire table. Approximate nearest neighbor, ANN, improves speed dramatically, and it trades a small
amount of accuracy. And we're talking ninety-five to ninety-nine percent accuracy for major performance gains. But we can measure those actually by recall, and all recall is, is how close our approximate search results RTO our exact search. To do this, ANN requires a new type of index within SQL Server called a vector index, and
the ones that were available to us within SQL Server are based on an algorithm called DiskANN. DiskANN, it is a developed by Microsoft. It's a graph-based index that connects similar vectors. Now, essentially, the search process here is we start at an entry point, we compare the
query vector to the nearest neighbor nodes in the graph, and we move to the closest neighbor. We repeat this process over and over and over, and we stop when no neighboring nodes are closer to our query vector than the node that we are already on. So we are navigating, traversing this graph structure and not scanning the entire table, which then provides a higher queries per second, low latency, and we're balancing CPU
memory and IO, just 'cause we're not doing those gigantic index scans. If we have a look at it, we can create a vector index with create vector index. Metric, cosine. We can use the three metrics that we want if, if we want to. Type, the only one available to us, type is DiskANN.
And then we can specify a max degree of parallelism when we create our index as well if we want to. But there's a gotcha with that, and we'll come to that in a second. Things to be aware of when we do this. This is a preview feature as of SQL Server twenty twenty-five CU six. So we need to enable preview features on our database.
And by creating a vector index on our table, it sets that table to read-only. So this would be one of the major reasons that we would separate out our embeddings data from our actual data within the database. Requires a single column integer clustered primary key, no replication to subscribers if you're using replication, and currently max stop that we specify
on our index is currently ignored. It's, it, it's referenced in the SQL Server twenty twenty-five known issues. I expect that to drop off at some point and be corrected in the CU. I also expect at some point that the creation of the index on a table setting it to read-only will be gotten rid of as one point as well.
But for now, it still sets it to be read-only. Okay. And again, this is how we perform a vector search. It's very similar to vector distance. We're saying declare our search text, find me a restaurant where, say, we say a great atmosphere here. AI generate embeddings for our search text
using our model, and then we specify a query. So I'm selecting the restaurant ID, very simply distance from vector search. Function's a little bit different here, where we specify our table, our column, our search vector, our metric, and how many results we want to bring back. And here we go. When we do this, we get a vector index seek
and then a clustered index seek. Again, we're not scanning, we're using these indexes, much more performant, much more, less CPU, less IO, less memory used. A lot better than the vector distance. Trading off that small amount of accuracy, ninety-five to ninety-nine percent accurate
for major performance gains. Let's dive into the last demo. Okay, so I'll close this one down, and we'll have a look at vector search. So first thing to do, this is preview features. So we're gonna enable preview features on the database.
And let's create our vector index. So vector index here on embeddings, restaurant reviews. Sorry, on the restaurant review embeddings table on our embeddings column. Gonna go with cosine. Have to use DiskANN, it's the only algorithm supported in creation of this index.
And then max stop. I mean, it's currently ignored, but you might as well specify it. Three, two, one. And that'll go off. Table's really small, so that'll create the index fairly quickly. There we go.
New DMV as well for vector indexes. We can see it in our database. There we go. And so, just to confirm, let's try and There we go. I actually love it when Microsoft gives us error messages that tell us the exact issue that's there, and it tells us, right, that
data modification failed because it has a vector index on it. Okay, so that table is now set to read-only. So that's something to be very aware of when you're working with vector indexes and SQL Server data. Okay, so let's see if we get any different. Let's do a query search here.
Let's find me a restaurant with a good atmosphere, and we're gonna pull back from our restaurants table with our distance pulled out from our vector search, our, function. Three, two, one. Off we go. And we've got a whole bunch of them there.
Okay, we've got Texas, Texas Steakhouse again. Let's have a look at them and see why it's pulled that out. Texas Steakhouse and say seven, seven, seven. Okay. Nice atmosphere. Food was amazing. Atmosphere was fab.
Food was good. Okay. Okay, that's kind of capturing the meaning of that there and then bringing these restaurants back. So we've got captured the meaning again of that review data, compared it to the meaning of our query data, and it's returned, amongst others, these two restaurants.
All right. Let's try another one. Now what I'll do, instead of having to do that big long, query each time, let's create a store procedure to perform those searches. Three, two, one. DBO search restaurants. And now I can just say, "Okay, where do people say the food reminds them of Mexico?" Let's
try this one. Okay, we've got the Mex, Adobo, Republic, Republic of Grill. Okay. Let's have a look at these two. Okay. Authentic Mexican food, excellent Mexican food. We are from Arizona, and this Mexican food ranked up there with what we used to get.
Okay. Not bad, not bad. True Mexican cuisine. Okay. We haven't done any keyword searches here. Where does the food remind them of Mexico? And we've got things like authentic, true Mexican cuisine, capturing the meaning of that
review data and comparing it to our query data. Okay, let's do one more. Good place for a casual date night. Burrito restaurant, but all right. Let's, let's see what we get. Texas Steakhouse, and they keep popping up.
Okay, we're gonna get some rep-- rep-repetition here. It's a very small data set, but let's investigate a couple of other ones, shall we? Town Square. We'll have a look at that one. There we go. Oh, lovely romantic meal here with my husband. Lovely warm bar, great food.
The staff are really attentive and nice. So yeah, picked-- Is that my girlfriend and I had dinner here? So pulling that meaning out, comparing it to our query vector and returning, amongst others, these reviews. Okay, we've got a couple of minutes left.
Would anyone like to ask the Burrito Bot a question? We got anything there, Dave? Yeah, I've got a couple for you. Um- Go on then. So- See how my typing is. Yeah. What about find me a restaurant with the freshest ingredients?
But with fresh ingredients. Let's just, let's do that. Yeah. Fresh ingredients. Three, two, one. Let's have a look. Okay, let's do, Chopped. I don't know why that would be in re- maybe I need to sanitize my data a little bit better,
but let's have a look at why it's pulled those out. Oh, really fresh ingredients. Okay, we're gonna do Cool Oh, well, whoop, and it was awful. Okay, remember we are pulling out one review here. Healthy food option, tastes so good, really delicious, has the best ones.
Okay, so again, oh, healthiest food truck in Ireland. Delicious fresh, bright food. All of it the freshest and tastiest. So again, okay, could've done a keyword search on that one. But again, it's captured the semantic meaning Well, sorry, it's the meaning of the data- and
compared to our qu- embedding data. Should we do one more? I think we've got time for one more. Yeah, there's another question. Um- Go on. Rather than, obviously you can search on star rating, which is the best- Yes and that's easy to do.
That's, that's simple. We've been able to do that for years. What would you say could you get it to search for if I care more about quality than price? Let's try. Could you find me, Well, how would you rephrase that? Uh- A restaurant- What about where should I go, yeah, where should I go if I care more about quality than price?
Should I go if I care more about quality than price? Let's see what I have no idea what this will come back with. Let's have a go. Okay, we've got a few here. Votso. Let's drop that one in.
And Black Mar- let's pick Black Market. Three, two, one. Okay, let's have a look. Price for All right, maybe not. Super trendy spot. Great mix with Great indoor lounge, soulful vibe.
Interesting. I'm not sure why it's pulled those ones out. We'd have to dive Oh, everything is a bit overpriced. Might be why it's pulled that one out there. Remember this is reviewed it. Okay, service review. But okay, this is not- Yeah.
That's a really good one actually, because it does kind of show this is all dependent, like everything in SQL Server, very dependent on the data and what is in these reviews. So it's gonna give you im- The top one says about quality. And Andrew, if you just scroll to the right. Oh, yeah. Well- Line number one.
Keep going to the right. Oh, did I miss it? Yeah, Keep going. It says, "The best place," blah, blah, blah. "Marina Market is better for food quality." Oh, yeah. Okay, cool. There we go.
It's hidden away right at the end of the review, but it's called out. It's not bad. Not bad. Okay, so let's do I'll do one more, because I like this one. What I'm gonna do here is I'm creating another store procedure. The eagle-eyed of you may have noticed I had another AI model in that, in my Azure Foundry.
So if I create this one, there we go, and let's now jump into the Burrito Bot. And what I'm doing here, what that store procedure update does is it se- performs a vector search, but it also passes the reviews back to a ChatGPT model that can give me an updated response. So, so let's do, where is the worst restaurant in Ireland?
So we're going off, we're doing a search. There we go. Based on customer feedback, Burritos and Blues in Cork appears to have the worst reputation. Reviews mentioned cold, flavorless food and very poor, hostile service. Many customers strongly advise against eating there.
So okay, we've really captured the meaning there, quite happily, but this is how we went from just running SQL Server store procedures to do a full-blown Burrito Bot running, Burrito Bot dash, burrito-bot.com. Capturing semantic meaning of Google review datas and providing recommendations for restaurants in Ireland, or not providing recommendations for restaurants in Ireland as
is the case here. Jumping back, a final thing I have for you is the links to the GitHub resource. So, if you click the link there, or go to the link there, I should say, can't click it, it will take you to the GitHub repo. The QR code there as well will also take you to the GitHub repo where, as I mentioned, all
the slides for the, sorry, all the slides for presentation today and all the code for all the demos. And you don't need anything else other than a SQL instance and an AI model where you can just run through them one by one and execute exactly what we've done here today, playing around with it, seeing what type of results you can get, where it falls over, where it excels.
It's all there for you. Do we have any last questions? No. No further questions in there, Andrew. Fantastic. Well, do remember if you do have any questions after today, please feel free to reach out to us.
We're always willing to talk about this stuff. But from myself and Dave, thank you very much for attending. Have a great day.
Andrew Pruski
Principal Field Solutions Architect & EMEA Specialist Field Tech, Everpure
Dave Ruddle
Senior Systems Engineer, Everpure
Semantic search allows applications to find relevant information based on meaning, rather than exact words. In this session, we'll look at how SQL Server 2025 implements this technology using native vector support and demonstrate how it can be used to build intelligent search experiences.
You’ll see practical examples for generating, storing, and querying vectors, plus guidance on evaluation and performance trade-offs. Attendees will leave with an actionable plan to pilot semantic search and measure impact in their environment.
Key takeaways:
- Understand how vector search differs from keyword search
- Generate and store embeddings in a repeatable workflow
- Perform semantic searches using SQL Server's vector capabilities
- Evaluate performance impacts of vector indexes
Additional Resources
PURE //
RESOURCES
Github
The Burrito Bot
An AI-powered semantic similarity search application that provides burrito restaurant recommendations using SQL Server 2025 vector search capabilities.
PURE //
RESOURCES
29 - 30 September, 2026
Pure Accelerate London
Accelerate your data advantage. Pure Accelerate London is now a multi-day experience designed to give you more value from every hour onsite.
PURE //
RESOURCES
Community
Welcome to the Everpure Community
Our community is a collaborative place to learn about our products and ask questions. Check out our most popular conversations.
We Also Recommend...
Personalize for Me
My Updates
No updates at this time.