Open source, on-disk vector search with LanceDB

Foreign.

Welcome to Practical AI. If you work in artificial intelligence, aspire to, or are curious how AI related technologies are changing the world, this is the show for you. Thank you to our partners at Fastly for shipping all of our pods super fast to wherever you listen. Check them out@fastly.com and to our friends at Fly. Deploy your app, servers and database close to your users. No ops required. Learn more@flyio.

Welcome to another episode of Practical AI. This is Daniel Whitenack. I am CEO and founder at Prediction Guard, and I'm joined as always by my co host Chris Benson, who is a tech strategist at Lockheed Martin. How you doing, Chris?

Doing good today. How's it going, Daniel?

Oh, it's going great. I was just. Well, we were just remarking before actually starting the recording that one of the great things about doing these episodes is that we get the excuse to bring on the show the coolest open source and tooling and other projects that I'm using day to day and get the chance to interact with. And one of those is Lance db. And we're really excited today to have with us Cheng Shi, who is the CEO and co founder at Lance db. Welcome.

Thanks. Hey guys. Super excited to be here. Thanks for having me on.

Yeah, yeah. Well, first off, congrats on, on all your success. I was scrolling through LinkedIn and saw like a video of Lance DB up on the NASDAQ screen in, in Times Square. So that, that was cool to see. That must mean good things, I'm assuming.

Yeah, it via Brex and also Essence vc. So big thanks goes out to them.

Cool, Cool.

Yeah, well, I mentioned I've had a chance to look through some of what you're doing and actually use it day to day. Actually, that was a result of a previous episode that was, I think, titled Vector Databases beyond the Hype with Prashant. I think the question that we asked him was like, oh, there's all these vector databases. You've compared all of them. What are some of the things that stand out or some of the vector databases that stand out in terms of what they're doing technically or how they're approaching things. And one of them he called out was Lance DB. I think in particular he was talking about kind of on disk index stuff. And so I'm sure we'll get into that in a little bit more. But that's how I got into it. So I recommend listeners maybe go back and get some context from that episode. But as we get into things, could you maybe give us a little Bit of a picture as to how Lance DB came about. I know there's a lot of hyped vector database stuff out there and people might not sort of realize how these things were developed, how they came about, what the motivation was. And so if you could just give us a little bit of a sense of that, at least for Lance db.

Yeah, absolutely. And first I wanted to also give a big shout out to Prashant as well. As you were saying, there's a lot of hype and noise in this area. There are a lot of different choices. And for users and developers who are building generative AI tooling and applications, it's always kind of confusing which one is good and should you listen to the marketing from one tool versus another? It's great to see someone with an engineering background who can write so well to actually take the time and just try out a ton of different tools and interview a bunch of different companies and come to his own conclusions. I'm super happy and excited that he's a fan of LAN cv and we hope to make that better for him and also all of our users. So back to LanCV, I think. So. We started the company two years ago at this point, and we didn't start out as a vector database company actually, because I think if you kind of remember, ChatGPT is barely one year old.

Yeah, the dawn of AI.

Yes, exactly. And so the original motivation was actually serving companies, building computer vision and building new data infrastructure for a computer vision. So I had been working in this space for a long time. I'd been building data and machine learning tooling for about almost two decades at this point. I started out my career as a financial quantity and then I became involved in Python open source. I was one of the original co authors of the Pandas library and that really got me sort of excited about open source, about Python and building tools for data scientists and machine learning engineers. And so at the time, this was in 2020 and 2021, what I observed was at the company I was working for 2BTV, so it was a streaming company. So we dealt with both machine learning problems for tabular data and also for unstructured data like images and the video assets and things like that. And what I had noticed was that anytime a project touched this multimodal data for AI, from images to, like the text, for, you know, let's say subtitles or summaries to the poster images, these projects always took a lot longer. They were much harder to maintain and it was difficult to actually put into production at the same time. So my co founder Lei, who I had met during my days at Cloudera, he was working at Cruise and sort of dealing with the same issues. And so we put our heads together and our conclusion was that, hey, it's not the sort of top application or workflow layer or orchestration layer that's the problem, it's the underlying data infrastructure. If you look at sort of what's been out there, like, you know, Parquet and. Org has been around and they've been great for tabular data, but they really, really suck for managing unstructured data. And so we essentially said, hey, what would it take to build a single source of truth where we can toss in the tabular data plus the unstructured data and give much better performance at a much lower cost, total cost of ownership, an easier foundation to build on top of for companies dealing with a lot of vision data. And so this comes in handy when you want to explore your large vision data sets for, let's say, autonomous driving. This comes in really handy for things like recommender systems and things like that. So we started out building out that layer, that storage layer in the open source and that took about a year's worth of effort to really get to a shape that is usable, kind of like Parquet or. Org and other formats in these tools. And that was when generative AI became really burst onto the scene and became sort of a revolutionary technology. And what happened at the time was we had originally built in Vector index for our computer vision users to say, hey, let's deduplicate a bunch of images or let's find the most relevant samples for training for active learning and things like that. It was that open source community that discovered, hey, this can be really good for generative AI as well. That's when we separated out another repo to say, hey, this is a vector database and it's much easier to communicate with the community than to say, hey, you're looking for a vector search, use this columnar format. And so that's how we got onto this path.

Quick question for you. It's really a follow up to something you said. It's been a couple of moments now as we were going through that, but I was just curious when you were talking about kind of going through the analysis on the top workflow versus whether it was infrastructure and you said y' all concluded infrastructure. I was just wondering, you kind of went on past that into that, but I was kind of wondering, how did y' all come to that determination? For those of us who are not deeply into that thought process. I was wondering where your head was.

At when you were doing that.

Yeah, it wasn't an easy decision or conclusion thinking back. It was kind of, you know, so it was like 2022 initially seemed pretty crazy when we sort of first came up on it. Right. If you think about it, it's like, why would you make a new data format like in 2022? Like, parquet has been working so well, and I think it was really observing the pain in our own teams. And also we went out and interviewed a lot of folks managing unstructured data. And so for them it was one data was split into many different places. Like, the metadata might be managed in Parquet and the raw assets are just dumped onto local hard drives or S3. And then you might have other tabular data managed in other systems. And they would always talk about how painful it is to stitch everything together and manage it all together. And some of the outcomes are like, it's really hard to maintain those data sets in production. Like, you have a parquet data set that has the metadata and Then links to S3 or something like that to all the images, and then somebody moves that S3 directory or something like that, and now all of your data sets are broken or something. Like, we would interview folks are like, hey, what are you doing to explore your visual data sets and things like that? And they're like, well, you know, I use MacBook and there's this app on Mac called Finder, and if you single click on a folder, it shows you a bunch of thumbnails. Right. It was sort of this horrible way to actually work with your data. But it was because it was so hard to manage all of that that machine learning engineers and researchers were stuck with these subpar tools.

You mentioned kind of this transition of thinking from some of the original use cases that you were talking about with computer vision to this world of generative AI that we're. That we're living in now. From my impression, from an outsider's perspective, it seems like Lance DB has kind of positioned itself very well to serve this kind of generative AI use cases, which I'm sure we'll talk about in a lot more detail later on. I'm wondering from your perspective, like, how has that overwhelming demand for the generative AI use case kind of changed your mindset and direction as a company and a project and open source tooling and all of that, and how do you envision the kind of what you're targeting as the use cases moving forward?

I guess I think certainly generative AI has brought in a lot of different changes and new thinking. One was the sort of focus around use cases of semantic search and just retrieval in general. I think with the advent of generative AI, I think retrieval becomes much more important and ubiquitous for us. What that means is increased investments in terms of getting the index to work really well and really scalable and then sort of making that data management piece to work really well as well, and integrating with frameworks for RAG and for agents and for just generative AI in particular. When we started out, inevitably we were dealing with multi terabyte to petabyte scale vision data sets and things like that. And we're still dealing with a lot of that. But for generative AI, I think there was a renewed focus on ease of use because a lot of users are coming in who don't have years of experience in data engineering or machine learning engineering. And what they're looking for is a easy to use and easy to install package that doesn't require you to be an expert in any of these underlying technologies. We also spent some effort into, okay, that was sort of the motivation behind us making lansdb the vector database, one open source and two embedded, because we felt like there were lots of options on the market that required you to say, figure out, okay, what is the instance I need, how many instances do I need, what type of it? Okay, now I have to shard the data and blah, blah, blah. And coming from that data background, what I had been working with a lot is like SQLite or DuckDB that just runs as part of your application code and would just talk to files that live anywhere. And it was super easy to install and use. So that's sort of what gave us that inspiration to make an embedded vector database.

You had just got into this sort of idea of embeddings, sorry, embedded databases, which. Well, embeddings are related, but that's another topic. But the idea that Lance DB is embedded, you mentioned DuckDB and other things that kind of operate in the same sort of sphere. I'm wondering for those that maybe are trying to position Lance DB's vector database tooling within a kind of wider ecosystem of vector databases and like plugins to other databases that support vector search. Could you explain a little bit about, like, what does it mean that Lance DB is embedded? Like, what does that mean practically for the user? Maybe people aren't familiar with that term quite as much. So what does that mean practically for the user? And are there other kind of like general ways that you would differentiate Lance DB's tooling and the database versus some other things out there.

So I love sort of geeking out about these topics. So at the very bottom layer in terms of technology, I think there's a couple of things that fundamentally sets LANCB apart. One, as you mentioned, is the fact that it's embedded or runs in process. I think we are one of two that can run in process in Python and we're the only one in JavaScript that runs in process. Number two is the fact that we have a totally new storage layer through Lance columnar format. What this allows us to do is add data management features on top of the index. And then number three is the fact that the indices, the vector indices and others in lancb are disk based rather than memory base. So that it allows us to separate compute and storage and allows us to scale up a lot better. Right. So those are kind of the big value propositions that these technological choices bring to users of LanCV. So number one, ease of use, number two, hyperscale ability, number three, cost effectiveness. And then number four, the ability to manage all of your data together and not just the vectors, but also if you think about it, the metadata and also the raw assets, whether they're images, text or videos.

Could you kind of describe a typical use case of a developer doing this where you're kind of taking those features that are distinguishing Lance DB from other possibilities, other competition, but just talk about what that workflow looks like or if there is a major one or a couple, and just kind of get it very grounded so somebody that's listening can kind of understand how they're going to do it from A to Z when they're integrating Lance DB into their workflow.

So there's a couple of sort of prototypical workflows that we see from our users. I think at the smaller scale for lancb, you're installing it via like PIP or NPM or something like that. And in general you get some input data that comes in as like a Pandas data frame or maybe a polar's data frame and then you interface with an embedding model. You can do that yourself or you can actually configure the LANCB table and say hey, use OpenAI embeddings or hey, use these hugging face embeddings. LANCB can actually take care of all that. So it's a pretty quick sort of data frame to lancb and then you can search it and then that comes out as, you know, data frames or Python dicts. Or things like that that plugs into the rest of your workflow that are likely data frame or pedantic or Python dict based. So that's number one. And then kind of number two is really these large scale use cases where some of our users have anywhere from like 100 million to multiple billions of vectors in one table. And that's a much bigger production deployment. And typically what makes Lance DB stands out in that area is one, it's very easy for them to process the data using a distributed engine like Spark and they can write concurrently and get that done really quickly. I think we're one of the few that offers GPU acceleration in terms of indexing. So even for those really large data sets, you can index pretty quickly. And then number three is because we're able to actually separate the compute and storage, even at that large vector size, you don't really need that many query nodes. You can actually just have one or two fairly average and commodity query nodes that runs on your storage of choice, depending on what latency requirements you want, and then just have a very simple architecture. For these types of architectures, the query nodes are stateless and they don't need to talk to each other. So when you need to scale up or when a node drops out and has to come back in, there's no sort of leader election, there's no coordination. It really lowers the complexity of that whole stack. So another great example of this kind of architecture and the benefits that it brings is Neon, the Neon database. So I think Nikita, who's the founder, recently had a good Twitter thread about the difference between Neon and other databases, and he called it shared data versus shared nothing architecture. I think that's also what we strive to deliver in LANCB versus other vector databases.

Yeah, I know. One of the things that I really enjoyed in trying out a lot of things with Lance DB is I can pull up a COLAB notebook, right, and try out like, I can import Lance db, I can import like a subset of the kind of database that I'm going to be working or the data that I'm working with, it all runs fine. I don't have to like set up some client server type of scenario. And then when people ask, well, how are you going to, how are you going to push this out to a larger scale. The appeal of just saying, hey, well, we can just throw up this Lance DB database on S3 and then connect to it. That's a very appealing thing for people because also those storage layers are available everywhere from on Prem to Cloud to whatever sort of scenarios you're working with. So it's very, very flexible for people. Could you explain a little bit? Because this is something like I've been asked a couple times, but so this is my selfish question because I have you on the line so you're helping me with my own day to day work. But when I'm, when I'm talking to like some people, clients that I'm working with, I'm like, oh, we can just throw this up on an S3 and then access it. Usually their question is something like, well like because they have in their mind a database has a compute node and like the somehow the performance of queries into the database is tied to the sizing of that compute node and maybe like how that's sort of clustered or sharded across the database. And then like this idea, oh, I'm just going to have even just a lambda function that connects to S3 and does a query right like this kind of in some ways it like breaks things in people's mind. And so a lot of times the question was like, how does that work? How can a query to this large amount of data be efficient when the data is just like sitting there and in S3 or in another place. So could you help with, help me with my answer, I guess is what I'm asking.

Yeah, absolutely. So this goes back to what we talked about earlier with separation of compute and storage. And if you've been sort of steeped in like data warehousing, data engineering land, this has been a big arc of data warehouse innovation in the past decade by allowing us to scale up the storage versus the compute separately. This is the thing that makes these systems seem magical where you can process huge amounts of data on what seems like pretty commodity or pretty weak compute. And so the analogy that I like to make with these situation is kind of like a lot of us are familiar with let's say like DuckDB demos or videos and you could see instances where DuckDB is processing hundreds of gigabytes of data on just a laptop and in a very vast amount of time. And they are able to spit out results and almost interactively. And there are companies from like motherduck to, there's a new company called Bow Plan that is looking to essentially distribute DuckDB queries on AWS Lambdas. It's basically the same thing. It's all about the separation of compute and storage. And that's only possible if you have the right underlying data architecture for storing vectors and the data itself.

And just for someone that like is not a database developer. Can you describe in any words like the generalities of that data structure that enables such a thing?

Yeah, so it's two things. One is the one is the columnar format. So typically, you know, from Gen AI to machine learning, you can have very wide tables, but typically a single query only needs like a couple of columns.

So.

So columnar format allows you to only have to fetch and look at like a very small subset of that data. Number two is that columnar format needs to have be paired with an index, like the vector index in this particular scenario. And that vector index, in order to give this separation of compute and storage, has to be based on disk. So you have to be stored the data on disk, not force the user hold everything into memory and then be able to access that very quickly. And then number three is how to connect that index with the columnar format. So a columnar format like Parquet does not give you the ability to do fast random access. So even if you had that good index using Parquet, you would not be able to get interactive performance in terms of queries. And it's only by having a new columnar format like Lands that can give you fast random access and fast scans that you can successfully put these two together and deliver the thing. So those are the three sort of big pillars that I think in our data architecture that makes this possible.

While we were talking here, I'm going through GitHub on your repo and stuff and was surprised at something that kind of prompting the next question. It looks like you're really addressing a wide range of different types of needs. And so there's obviously Python, as you would expect, but you have JavaScript. And then I was delighted to discover that there's a Rust client in there, which is when I'm not doing AI specific things most of the time. That's my language of choice these days. Could you talk a little bit about kind of two things, the broader, like what you're trying to achieve, like how you choose what languages to support and how you're getting there. And then if you'll scratch my itch, what is your intention with that Rust client? Is it ready? What does it do? Just because I'm fascinated with that. Sorry.

Yeah, absolutely. I love talking about Rust. The Rust package is actually not a client. But so on the core of both the data format and the vector database is actually in Rust. So the Rust crate that we have is actually the database or the embedded database. And so, and we actually build, for example, the JavaScript again, the same thing with JavaScript. It's not just a client, but it's also an embedded database in JavaScript. So that is actually based on top of the Rust crate and kind of like you have in say like Polars or something like that, you have like a Rust core and then you connect that into JavaScript. So we had actually started out in 2022 writing in C, because Parquet is written in C, you know, like serious data people and database people write in C. Right.

Until they find Rust, of course.

Right. And it was sort of a hack project during Christmas time in 2022, at the end of 2022, where we had to did a hack project for a customer actually, and where we had to actually re implement partially the RE path for Lance format. And what we found was just. It was so good that we decided to just actually rewrite everything in Rust. I think biggest things were we were a lot more productive. We rewrote roughly six months of solid C development in about three weeks with Rust and we had. This was like us learning Rust as beginners as we went along. A lot of that initial Rust code has again been rewritten over the past year. But it just made us feel a lot more productive. And then number two is the safety that Rust offers you has been amazing with C, like every release. It just didn't have a good feeling. It was almost like, you know, where's that next seg fault going to come from? Whereas with Rust, you know, we felt very confident making multiple releases per week with major features and we did not see anywhere near the sort of issues that we saw with C. Right. So everything has been really great. I know that Rust has become really popular now for actually even with vector databases like Quadrant, I think, is Rust Pinecone. They're not open source, but they publicly said that they've written in their whole stack in Rust as well.

So one more question from you along the same line before I let it go, because we've hit that sweet spot that I love. Do you think, and this is not specific to Lance db, but based on what you're saying, clearly you're thinking ahead on these things as we go forward and you see both the AI applications and you see the different types of workflows and infrastructures, you know, becoming broader and more supportive. The multi language aspect of getting out of only Python, for instance, do you, do you foresee that as a convergence where you're seeing language agnosticism developing in this space as it has in other areas of computer science? Or do you think that we're still going to be kind of locked in on the current sets of infrastructure and tooling, very Python oriented for the indefinite future. What is your thinking along those lines?

So I think generative AI definitely changes the picture in that I think there's a very large TypeScript JavaScript community that has been brought into the arena to build AI tools. And so I think this is also an underserved segment where it's not just vector databases but data tooling in general lags far behind in JavaScript TypeScript land versus Python. And I think there's a real opportunity for the open source community to create good tools for this part of the community as well.

I want to hear about some of the actual use cases that you've seen people implement with Lance db Maybe if there's ones that stand out like, oh this was cool because whatever it was, it's they used it at scale or it's like fits a very typical generative AI use case or whatever. And then maybe something that surprised you in terms of oh, I didn't always when you put a project out into the world, there's these things where, oh, I really didn't expect people to be using it that way. But yeah, that sort of makes sense. So do you think of anything that fits into one or both of those categories?

The use cases for LAN CB in the community that I see falls into three or four large buckets. One is of course Generative AI RAG and things like that. I think it's not so much the use of LANCB that I think is really cool, but it's the applications that people build with it that is really cool and amazing. I think a lot of the applications that people build that is cool that really takes advantage of LANCB is things where you need RAG to be very agile and that you need it to be really sort of tightly bundled with your application. You can sort of call this RAG from anywhere and have it return pretty quickly and without too much complexity. And so this is where I see a lot of folks from like your standard like chatbots and chat with documentation to things like productivity tools where they build things that help people organize their daily schedules to much more high stakes things in production and code generation or healthcare and legal and things like that. And so there I think typically you see vector data set sizes from the tens of thousands up to single digit millions of vectors typically. And so production means you really scale up both the number of data sets that you have and then the number of vectors that you have. And one of the cool things that I've seen that takes advantage of LANCB and Lance Format Uniquely is there's a code analysis tool that sort of analyzes your GitHub repository and plugs it into a, a rag like customer success sort of tool. And what they want to be able to do is say query the state of the database like this today versus yesterday versus a week ago to see, hey, was this issue fixed or not? And like what's still outstanding. And so LANCB Uniquely gives you this ability to version your table and also do time travel. So you can say any data vector database can do like give me the 10 most similar things to this input uniquely. But what LANCB gives you the ability to do is say give me the TEMO similar as of yesterday or as of a week ago. And we do that sort of automatically for you. Yeah. And then I think the other big buckets are, you know, E commerce and search and like recommender engines. Right. This is like the traditional use case for vector databases. And there you tend to see much bigger like single data sets that are say I want to store item embeddings maybe that's up to a couple of million, up to 10 million. I want to store item embeddings that could get up to hundreds of millions. You don't have as many tables, but you have potentially have very large tables. And then of course the last bucket is this computer vision, AI, native computer vision, either generative computer vision or things like autonomous vehicles and things like. Like that. And there's a whole sort of combination of more complicated use cases that enables active learning, deduplication, things like that. And the thing that is very unique about the use case of LAN CB in there is companies that are managing all of their training data in LAN CB and LANs format as well. So you can use the vector database to find the most interesting samples and then you can actually use the tooling on top of the format to essentially keep your GPU utilization high and keep your GPU fed very quickly during training or if you're fine tuning or if you're running evals and things like that.

Yeah, so cool. One of the things that has been most fun for me recently is this combination of an LLM, Lance DB and DuckDB where you can create these really cool. So if I'm using an OpenLM that can generate like SQL queries or something, but I have like all of these different SQL tables, like what we're doing is like putting descriptions of the SQL fields and tables in Lance db and actually on the Fly like matching and pulling those to generate a prompt which goes to the LLM to generate the SQL code which is executed with DuckDB. And this gives you like the kind of really nice natural language query to your data type of scenario which has been really fun to play with.

That's really good to hear actually, sorry to interrupt so because you kind of nerd site me. So one of the things that's really cool about DuckDB is its extension mechanism. And so I think they've also published like a extension framework for rust based extension. And so we have sort of a basic integration going there and I think in New Year what you can expect from us is actually we're going to be spending a little more time to make that integration be more rich. Meaning our goal is for you to be able to say to Write like a DuckDB UDF to do vector search and then the results come back as like a DuckDB table where you can then run additional query like DuckDB queries on top of that. And so, and so and the same thing with like pollers. Right. So you can. And the goal is to essentially make it so that vector database is no longer a thing that you even have to think about. It's people are generally more familiar with like DuckDB or Polars as the sort of that tool that stitches together the workflow. So we just want that to make it feel even smoother and more transparent.

A couple of moments ago when you were talking about the use cases, you were talking about, you know, like autonomous vehicles and stuff and I was wondering if, if we could pull that thread a little bit more. It seems like it is a fantastic.

Chris loves drones.

Yeah, I love drones and I love things that are not by data centers. Yeah, I love things that are off on the edge, whether it be for inference or including training concerns that you may not have. All the things that we're so spoiled with with our cloud providers out there and it seems like, you know, there's many types of opportunities to use that. What's your thinking around that? Have you seen any use cases, any ideas for the future in that kind of autonomous on the edge world?

Yeah, definitely. So we certainly have. So some of our users are like robotics or device companies where they either collect data and write it as lance on the edge or they sort of collect data as like let's say proto buff or something like that and send it off to be converted into lance for like analytics, vector search and so on and so forth. I think in this world you're going to know it Better than me. But what I see is that one is the data super complicated. So especially with, let's say like a vehicle's types of use cases, you're getting visual data from the cameras, you're getting point clouds from the lidars, you're getting time series data from the sensor readings over time, and then you've got manual input data from like the auditors and the drivers that are sitting in the car. You're also getting metadata about the car, about the weather, about the geography and all that. Right. So being able to manage that and query all that together, I think will be super important for robotics and vehicles and any company that's putting things out there in the real world, that's generating data in the physical world. And I think that, yeah, I mean it's a really hard problem, but I think the potential is huge. Right, Because I think for AI, we're going from this era of very canned question answer to much more freeform question and answer. But it's still a little bit passive. Right? You're asking it for information. But what's really exciting would be like you marry these sort of generalized AI capabilities with a drone or a robot or something that can go out and be active out in the real world.

That gets me super excited about what's to come. I'm wondering, as we close out here, it's been a fascinating discussion at the end here. Could you just take a moment and make a few observations about what is exciting from your perspective right now in this sort of practical AI space? Because that's where you're living, what excites you about, you know, whatever it is, the next six months, the next year and what you think is kind of coming as this tooling rolls out there further and further, people learn to apply it better and better. What's exciting for you?

That's a great question. I think there are, there are lots of things that I think holds a lot of promise in the next six to 12 months. I think we'll see one is this explosion of retrieval kind of information retrieval tools. So we already see a lot of companies that are adding like generative AI in like customer success management and like documentation and things like that. And so I think we'll see a lot of applications providing value that is, you know, that can be also personalized and you know, not just like chatgpt style answers, but actually personalized to their own data or their own cases or things like that. And then number two is I see a lot of successes in very domain specific agents that are able to dive deep into legal or healthcare or some domain very specifically and build things that seem sort of magical, whether it's compliance or driving better outcomes or creating things that would democratize a lot of these sort of like very deep expertise type of domains. And then I think a little bit further out are generalized like low code to no code tools for you to build very sophisticated applications using generative AI through co generation and sort of creative, let's say creative interfaces and things like that. So those are things I think will deliver in the short term. And then personally I love games and I'm actually super excited about what generative AI brings to gaming. We talk about open world and things like that and this can be really open where you could just get lost for a long, long time in a generated world.

That's awesome. Thank you so much for taking time to talk with us. And please pass on my thanks to the Lance DB team for making me look good in my day job by giving me great, great tools that work really well. Appreciate what you all are doing and yeah, I just looking forward to seeing what comes over the coming months. And yeah, encourage our listeners to check out the show notes, follow the links to Lance db, try it out. It only takes a few minutes and hope to talk to you again soon. Thanks so much.

Thank you Daniel. Thank you Chris. It was super fun talking with you guys and if you have any feedback, please let us know. We hope to make you look even better in the new year.

Thank you for listening to Practical AI. Your next step is to subscribe now if you haven't already. And if you're a longtime listener of the show. Help us reach more people by sharing Practical AI with your friends and colleagues. Thanks once again to Fastly and Fly for partnering with us to bring you all Changelog podcasts. Check out what they're up to@fastly.com and fly IO. And to our Beat Freakin residents, Breakmaster Cylinder, for continuously cranking out the best beats in the biz. That's all for now. We'll talk to you again next time.