MyVector Magic: Elevating MySQL with AI Search

Oracle Ace Alkin Tezuysal joins leFred and Scott to introduce the MyVector plugin for MySQL Community Edition, bringing powerful vector search capabilities to your favorite open-source database. Learn how MyVector enables advanced AI and similarity search features, why this matters for modern applications, and how the MySQL community can easily get started.

-------------------------------------------------------------

Episode Transcript:

00:00.000 --> 00:25.000
Welcome to Inside MySQL: Sakila Speaks, a podcast dedicated to all things MySQL. We bring you the latest news from the MySQL team, MySQL product updates and insightful interviews with members of the MySQL community.

00:25.000 --> 00:32.000
Sit back and enjoy as your hosts bring you the latest updates on your favorite open source database. Let's get started.

00:32.000 --> 00:37.000
Hello and welcome to Sakila Speaks, the podcast dedicated to MySQL. I'm LeFred.

00:37.000 --> 00:38.000
And I'm Scott Stroz.

00:38.000 --> 00:47.000
Joining us today is Alkin Tezuysal. We know each other for a long time already and Alkin serves as Director of Services at Altinity Inc.

00:47.000 --> 00:55.000
Bringing over 30 years of experience in open source relational databases with deep expertise in MySQL, of course, and ClickHouse.

00:55.000 --> 01:08.000
He co-authored key references works including MySQL Cookbook 4th edition that came in 2022 and Database Design and Modeling with Postgres and MySQL in 2024.

01:08.000 --> 01:21.000
Alkin, you have been honored as MySQL Rockstar in 2023. And since this year, you are also an Oracle Ace Pro for MySQL. Congratulations and welcome to Inside MySQL: Sakila Speaks.

01:21.000 --> 01:23.000
Thank you very much, everyone.

01:23.000 --> 01:34.000
We're glad you're here. Alkin, as you may not know, this season of the podcast is dedicated to all things AI as it relates to MySQL and HeatWave.

01:34.000 --> 01:43.000
And you actually created or wrote a plugin for MySQL Community that kind of helped with that, MyVector.

01:43.000 --> 01:48.000
Can you give us an overview of what MyVector is and what problem it's meant to solve?

01:48.000 --> 01:50.000
Sure. Thank you very much for the question.

01:50.000 --> 02:00.000
And I'm very happy that this year of AI and HeatWave, everything that actually contributes to this technology because it's fairly new.

02:00.000 --> 02:06.000
It's been developing for many years, as we already know, but now it's in our hands.

02:06.000 --> 02:16.000
We can use it. We can definitely use it on our day-to-day activities, whether it's troubleshooting your dishwasher or your washing machine.

02:16.000 --> 02:20.000
But we could also use it in a business-wise database.

02:20.000 --> 02:29.000
So one correction I want to make is I am a contributor to MyVector plugin, not to author.

02:29.000 --> 02:34.000
The author is Shankar Iyer, and he's a developer for databases for many years.

02:34.000 --> 02:40.000
He's got a lot of experience where I've actually been presenting and supporting this project.

02:40.000 --> 02:49.000
And that's the small correction. Other than that, MyVector is a native plugin for MySQL that adds support for storing and searching high dimensional vectors.

02:49.000 --> 02:55.000
This is basically a very, in simple terms, what it does.

02:55.000 --> 03:00.000
And this has been in development for some time.

03:00.000 --> 03:14.000
And as we have seen other, you know, databases, other open source databases also went into this with the, you know, launching of AI to our, you know, end users.

03:14.000 --> 03:24.000
Adding approximate nearest neighbor n-search directly in SQL within MySQL database was kind of needed.

03:24.000 --> 03:29.000
And there has been similar implementations with MySQL.

03:29.000 --> 03:33.000
But MyVector is the open source version of that as a plugin.

03:33.000 --> 03:39.000
So just to wrap up that answer is MyVector column type for embedding storage.

03:39.000 --> 03:41.000
And there's a MyVector.

03:41.000 --> 03:46.000
There's a bunch of functions that MyVector distance for the similarity competition.

03:46.000 --> 03:50.000
Of course, it uses HNSW-based index algorithm, which is very popular.

03:50.000 --> 03:52.000
There's a white paper around it.

03:52.000 --> 04:01.000
It's not a rocket science or just something that was invented for MyVector that is known science.

04:01.000 --> 04:06.000
And basically, it provides an SQL native interface within MySQL.

04:06.000 --> 04:08.000
Hope that answers that question.

04:08.000 --> 04:10.000
Thank you very much, Alkin, yeah.

04:10.000 --> 04:22.000
It answers everything and very happy that you also, let's say, talk about the author that we already met also in Belgium recently.

04:22.000 --> 04:31.000
So I would like to ask you, so why is it important to have this similarity search indexes in MySQL then?

04:31.000 --> 04:40.000
Yeah. So again, going back to the AI-driven application, semantic search, product recommendation, question and answering, anomaly detection, etc.

04:40.000 --> 04:43.000
These really require a similarity searches.

04:43.000 --> 04:47.000
Have we done similarity searches in the past? Yes, we have.

04:47.000 --> 04:52.000
If you remember, this is a long, long time ago, but those technologies are still in effect.

04:52.000 --> 05:03.000
And we had search indexes like the Solr, this Phoenix, if you recall those, where we used to have a replica, generate index and search for it.

05:03.000 --> 05:10.000
I used to work for an e-commerce site and users would search for a product.

05:10.000 --> 05:15.000
And then we would also display the similar products.

05:15.000 --> 05:23.000
And in order to do that in MySQL, we had to use external services like, like I said, some search.

05:23.000 --> 05:25.000
So it is very important.

05:25.000 --> 05:29.000
But with the AI-driven application, it's not important anymore.

05:29.000 --> 05:30.000
It's a must have.

05:30.000 --> 05:35.000
Basically, you don't need to run a separate vector database.

05:35.000 --> 05:45.000
And basically, if the data is already in MySQL, you could use this technology using, you know, similarity search functionalities.

05:45.000 --> 05:49.000
Back at FOSDEM, you gave a presentation about MyVector.

05:49.000 --> 05:55.000
And over the weekend at FOSDEM, there were a lot of other sessions about vector and indexes.

05:55.000 --> 06:01.000
Has MyVector made any significant changes since you last talked about it in public?

06:01.000 --> 06:07.000
Yes, there was another public talk after FOSDEM that was a vector search conference.

06:07.000 --> 06:14.000
And we've had a bunch of talks about vector searches, vector technologies, which was around this open source databases, including MySQL.

06:14.000 --> 06:19.000
There were, I think, four or five MySQL talks around the vector search.

06:19.000 --> 06:33.000
From the development side, yes, there's one important improvement that was made that was the necessary support for binary distributions other than the Docker images.

06:33.000 --> 06:43.000
So we worked on those and built, you know, three different versions of MySQL binary distributions for testing, because it's more like a DIY.

06:43.000 --> 06:51.000
And you have to compile and everyone is not very competent enough or have enough time to compile MySQL.

06:51.000 --> 07:02.000
So we built images for 8.0 and 8.4 and 9x versions for easy testing.

07:02.000 --> 07:12.000
And there were some improvements on performance and index stability, of course, and so that's about it.

07:12.000 --> 07:18.000
Maybe it doesn't sound a lot, but this is a lot of work, basically, considering it's an open source project.

07:18.000 --> 07:21.000
Yeah, thank you. I can imagine it's a lot of work.

07:21.000 --> 07:31.000
So let's go now in the more technical, let's dig a bit in technical and a bit deeper there.

07:31.000 --> 07:41.000
So you said earlier that MyVector is using this HNSW, which is a hierarchical navigable small world indexes, right?

07:41.000 --> 07:48.000
Why was this type chosen over other or over alternatives?

07:48.000 --> 07:55.000
And do you know if or you yourself have tried alternatives or not?

07:55.000 --> 07:59.000
We would like to know a bit more about why that choice.

07:59.000 --> 08:01.000
That's a great question, actually.

08:01.000 --> 08:11.000
And when we first all heard or started knowing about this HNSW, hierarchical navigable small word for the n-search, like approximate nearest neighbor search.

08:11.000 --> 08:21.000
That was, it sounded like when I did my research and started reading about it, I think we met with you in London last year.

08:21.000 --> 08:26.000
We were talking about this, you know, the n-search and everything else.

08:26.000 --> 08:33.000
This is basically, I thought it was more like a de facto standard of the n-search.

08:33.000 --> 08:44.000
And it turned out to be that way because a lot of the other open source databases or implementations were circling around HNSW.

08:44.000 --> 08:49.000
And that's not to say that there are not other options out there.

08:49.000 --> 09:00.000
But usually when technologies like this launched, you don't go and reinvent the wheel, but basically build upon an existing technology.

09:00.000 --> 09:09.000
Since HNSW was widely available in terms of a knowledge wise, it was chosen HNSW.

09:09.000 --> 09:13.000
And, you know, it has high accuracy.

09:13.000 --> 09:16.000
It's a, it's got support for dynamic inserts and leads.

09:16.000 --> 09:19.000
And, and it has an efficient memory usage.

09:19.000 --> 09:21.000
These are the top three things that I know about it.

09:21.000 --> 09:31.000
But, you know, you know, from the other open source databases, like I said, the benchmarking were all circling around this.

09:31.000 --> 09:41.000
And if you were to use a different indexing, it would be very difficult to compare apple to apple from a different indexing perspective.

09:41.000 --> 09:52.000
So, I think, again, I'm, I'm not saying there are no other and methods there are, but they might be less accurate.

09:52.000 --> 09:54.000
They may have different, options.

09:54.000 --> 10:04.000
 but if you want to kind of, play something in the market that everybody knows, it would be better off, using the known, methodologies.

10:04.000 --> 10:11.000
So you've given me something I need to look up so I know what I'm going to be doing over the weekend, which HNSW.

10:11.000 --> 10:18.000
so does the data that we use need to be trained before it can be indexed?

10:18.000 --> 10:20.000
No, there's no training.

10:20.000 --> 10:23.000
Basically it's the, it's the, embeddings.

10:23.000 --> 10:30.000
The, the, the difference between the training and the embeddings is you just need to generate the embeddings.

10:30.000 --> 10:55.000
And that's where, that's where an additional step, like if your data is already in the database and you, you want to use this, vector, search technology using HNSW indexing for the n-search, you need to generate the embeddings, whether externally or internally with, with, with a service or, something like that.

10:55.000 --> 11:18.000
We, I know that there are some, the, the other types of index that are maybe less popular, that, index the embeddings, sometime they also need to, to have some training before, but, yeah, this one doesn't, which is, which is good because every time you want to, to add the data, whatever, it's quite complicated if you want to train it.

11:18.000 --> 11:19.000
Right.

11:19.000 --> 11:20.000
Yeah.

11:20.000 --> 11:25.000
Basically it's, it's, it's generate the embedding, insert in the MySQL and build the HNSW index.

11:25.000 --> 11:38.420
So, as you are discussing about, this, this index, what, what I'm, curious because, I also try, I try and check, different type of flow indexes to, to understand what they do and what it is.

11:38.420 --> 11:46.160
 but, I would like to know what's the size of this index compared to the actual size of the data, right?

11:46.440 --> 11:59.440
Because I know, and maybe it's the case, on your implementation that, the full representation of the, of the, of the vector is stored on the index on some of them or most of them.

11:59.440 --> 12:09.620
So I would like to know, if you have made some check there and, if, if the size is compared, right, to the, the, the full embeddings and the index.

12:09.920 --> 12:16.940
Just to recap that, the, the, the full vector is stored inside the index structure on a fast axis.

12:17.540 --> 12:22.560
So, so there's, there's no reference in back or anything like that.

12:22.560 --> 12:46.380
It's in the, this, we were talking about this, the size of the, index is that depends on the, vector dimension dimensions, a number of vectors that we're storing and, and then, and some of the parameters that, you know, per node, that, that index, but, we did some, some sizing and testing around it as yes.

12:46.380 --> 12:54.160
The accuracy increases when the dimensions are high as we know, and the size, size gets, gets higher.

12:54.440 --> 13:04.800
So, we're looking into this also, if there is any, any option to optimize that or, use some compression technology to, for this index.

13:05.160 --> 13:16.360
And, that's, something, is, is kind of, important to know that because this is not in, you know, DB, this is basically in the file system.

13:16.380 --> 13:19.080
And it needs to be, you know, placed correctly.

13:19.360 --> 13:32.200
You, you mentioned before how the, how MyVector is available and I know it's available as a plugin and just to clarify for our listeners, do you also provide the binary packages or do we still need to compile it, from the source?

13:32.980 --> 13:33.480
Yes.

13:33.480 --> 13:46.860
As I mentioned earlier, since FOSDEM the, the, the latest, release of, MyVector included, the, binary releases or, x86.

13:47.480 --> 13:53.840
And, and, that will, that is published in the GitHub page and, as open source.

13:54.100 --> 13:57.220
 so you no longer need to compile it from the source.

13:57.220 --> 14:02.360
If you want to test it out, just to plug in, my, um,

14:02.360 --> 14:16.980
I have launched a new blog technical blog page and started blogging and, I will blog about this so, so that, the listeners and, and the readers can actually, have a link available in the, in the blog.

14:16.980 --> 14:28.440
So they can go in and test it out and Docker images were available, but, binary releases also added, recently, for the, for the test.

14:28.440 --> 14:30.380
Awesome. Thank you, Alkin.

14:30.720 --> 14:42.720
So last question, do you know if there are already, some, companies or, users, using MyVector in production or not yet?

14:43.260 --> 14:45.500
There are some POCs going on.

14:45.860 --> 14:47.700
And as you know, this is open source.

14:47.700 --> 14:58.360
 there, there were some interest after force them, you know, we, people reached out, who were actually doing, this type of research and analysis.

14:58.360 --> 15:03.920
It was on the existing MySQL databases and, we provided help and information.

15:04.380 --> 15:05.540
They might have taken it.

15:05.600 --> 15:06.580
They might have forked it.

15:06.640 --> 15:08.980
They might have embedded into their existing implementation.

15:09.580 --> 15:16.500
 we don't know, but, as far as I know, there, there are a few POCs are going, they're testing with the existing data.

15:16.500 --> 15:29.520
So, as you know, just to add up since FOSDEM, there has been one shift happened in this type of technology, which is the MCP servers.

15:29.520 --> 15:45.640
So, that is one thing that I wanted to add over here with that shift, generating embeddings and, and actually having an MCP server that will actually add context to the n-search.

15:45.640 --> 15:53.620
Like a chat bot implementation made it, made things a little bit more, not only useful, but also interesting.

15:54.320 --> 16:01.380
So say you have, you know, support tickets or some, some data that's actually related to your, you know, internal customers.

16:01.580 --> 16:03.600
You could add MCP server.

16:03.800 --> 16:06.160
There are some public MCP servers.

16:06.320 --> 16:09.780
There are some open source and MCP server implementations.

16:10.080 --> 16:12.300
And, and we're also looking into that.

16:12.560 --> 16:15.560
And, I want to mention over here on my last.

16:15.640 --> 16:24.200
 talk during the vector search conference, I have actually, presented a MyVector with an MCP server demo.

16:24.200 --> 16:27.880
 and, and that recording is should be available.

16:27.880 --> 16:30.900
So for that, and, and, and actually it works.

16:30.900 --> 16:44.520
 this is pure MySQL open source, pure MyVector open source and pure MCP server open source with the, you know, clinical trials data, like the, one of the public data data sets that I've used.

16:44.520 --> 16:52.300
 you can actually ask questions and it'll answer, and then you can continue the chat using this, this, very given technology.

16:52.300 --> 16:54.060
That's awesome.

16:54.060 --> 17:00.060
I've actually been playing around with, writing my own MCP servers and having them interact with MySQL.

17:00.060 --> 17:14.880
And I think MCP is going to be, is going to wind up being pretty, being pretty big because it does give that, domain specific context that the LLMs can actually use to generate content or answers or whatever.

17:14.880 --> 17:18.120
So I, I'm, I'm interested to play around with that.

17:19.000 --> 17:19.520
Absolutely.

17:19.740 --> 17:20.120
Absolutely.

17:20.120 --> 17:23.100
This is very interesting development, very recent.

17:23.740 --> 17:28.440
a lot of people are experimenting right now with the MCP servers.

17:29.160 --> 17:44.300
MCP servers, are going to be, I think the salt and pepper of, or, or sauce of, of this technology, you know, having the vectors and beddings and the, you know, n-search, HNSW index and the MCP server.

17:44.300 --> 17:47.220
So they, it's going to complete the puzzle in my opinion.

17:47.600 --> 17:50.920
And, and also, like I said, I've already given a demo.

17:51.060 --> 17:53.840
We are also looking into this, this technology.

17:54.120 --> 17:59.220
 and, of course there's, that is also still under development.

17:59.740 --> 18:08.980
 if you're opening up for a public MCP, then it's actually your, your security and compliance is, is now outside again.

18:08.980 --> 18:16.200
We want to do, if you want to do everything internally, if you want to do everything in your own database, with your own security and compliance.

18:16.700 --> 18:20.660
So that's a game changer to have something, available for yourself.

18:21.260 --> 18:21.660
Excellent.

18:21.840 --> 18:23.140
So thank you very much, Alkin.

18:23.660 --> 18:25.060
 thank you for your time.

18:25.460 --> 18:27.740
We know you are on your boat right now, sailing.

18:27.960 --> 18:28.900
So that's awesome.

18:29.180 --> 18:29.580
Thank you.

18:29.640 --> 18:30.420
Thanks a lot, guys.

18:30.600 --> 18:31.120
Thank you, Alkin.

18:31.180 --> 18:33.120
And thank you for all your contributions to the community.

18:33.120 --> 18:36.880
That's a wrap on this episode of Inside MySQL: Sakila Speaks.

18:37.040 --> 18:38.280
Thanks for hanging out with us.

18:38.560 --> 18:42.320
If you enjoyed listening, please click subscribe to get all the latest episodes.

18:42.600 --> 18:45.540
We would also love your reviews and ratings on your podcast app.

18:45.860 --> 18:50.080
Be sure to join us for the next episode of Inside MySQL: Sakila Speaks.