From Big Data to DuckDB: Ryan Boyd (MotherDuck) on Hyper-Tenancy, Duck Lake, and Making Data Fun.
Hey everyone, Ryan Boyd here. I'm a co-founder at Motherduck and I'm quacking excited to be speaking at AI by the Bay taking place in Oakland, California from November 17th through 19th. I'll be speaking on analytics data infrastructure for AI. LLMs are super magical, but they're bad at facts and especially bad at aggre aggregating data facts within a business. I'll talk about the infrastructure needed to make LLMs work alongside analytics database engines and the hyperteny architecture we built at motherduck with duck DB to make it easier more efficient and less risky to have your LLMs interacting with your data warehouse. Hello everybody. I'm Alexi Kraov, the founder and organizer of AI by the Bay, the longest running deepest technical independent still standing command open source conference in the Bay Area running for 11th year in beautiful Oakland, California. We call it Oakland Riviera on the shores of Lake Merit in the Oakland Scottish Ride Center
And we're thrilled to have Ryan Boyd, founder of Mother Dog with us and it's a major supporter of the conference and Doug DB is one of the most fun things which happened to computers in the recent memory. So I'm kind of joking to people there are two things happening in computers. It's AI and DD DB and anybody who goes to any kind of events with Doug DB can feel the vibe and the small data conference. Last year was super fun and small data conference SF is coming up again right November 4th to 5th I should go there. So uh Ryan question why DB why is it so much fun? Why developers why do they love it? So I think you know well first of all I'm slightly embarrassed here on behalf of of Hanos and Mark who are the the creators of of Duck DB. I think what they've created is is magical because of its efficiency and its focus on ease of use, developer experience, whatever you want to call it, right? You know, we have we have spent the last two decades building infrastructure for building infrastructures sake and not really focusing on is it the right size of infrastructure for our data problems. people like myself uh back when I worked on Google BigQuery a decade ago, you know, oversold on everyone on like you need this huge infrastructure. It's just not true
You don't need a huge infrastructure for the vast majority of use cases and it comes at a cost to build that huge infrastructure. It comes at a cost of maintaining it. It comes at a cost of the complexity and debugging it, going through those uh those Java stack traces with Python in between as I'm sure every person using Spark is familiar with. So, you know, duct DB was created really just to say let's get something super lightweight, super efficient, focus on what people really care about when working with data. And you know that's everything from like are your queries fast to is the SQL that you're writing understandable and the SQL that you're writing easy to use. And you know it started off as this embedded database that everyone is just like okay that's just for smallcale applications or what have you. You know we have this conference small small data SF. The reality is people are doing huge things uh with duct DB just many duct DBs and you know at mother duck we call that scaling hypertendency but the the reality is is that vast majority of use cases can can work with a simple database engine like duck DB and I'm just really happy to be working on it because of the name that's it's all about the name man it's all about the name uh and I get to have ducks cute ducks which you can kind of see peeking peeking from behind me and you know let's just make data fun again
Uh and that yes that is the name is part of that but also just the simplicity ease of use the efficiency the reduction in costs that you get by using something like duct DB. I want to give credit to Hannes as well. I've just seen him talk keynote PI data Amsterdam right in his uh hometown of the institute which gave birth to Python and DTB. I I really like how you guys destroy legacy architecture. So it's last year small data you presented basically the talk that big data is dead. It was a bunch of like it's a matrix, right? A matrix of distributed computers. They'll go away. There is one big beefy computer running one big beefy duck DB supplanting it
And so Hannis show the client server architecture from ' 90s and 80s, right? It's like well like there is like this master server in the cloud and a bunch of leaves and this is all now gone again. There is a duck DB instead of all of that. So why do you guys like to like tear down all these legacy architectures and what's coming in instead? And and a tricky question isn't like mother duck in the cloud another kind of this like now you you hadn't process database and now you put them all back in the cloud. So how does that work? Walk us through it. >> Did you have you ever played with Legos when you were a kid? >> I was brought up a Soviet Union. I had like wooden branches and >> you build them up then you tear them down and then you build them up again. >> I mean our our industry works in cycles, right? And and the thing is is that there's plenty of interdependencies here. The quote unquote big data architecture where a single query would get distributed across thousands of nodes was needed back when I worked on Google BigQuery for a lot of use cases
The thing is is that like compute has advanced, processors have advanced, memory has advanced, disk write, read write speeds and other IO have advanced and that creates different opportunities on the software side to to simplify things. you know, if you looked I think one of my my queries that I demonstrated with Google BigQuery uh that took 20 odd some odd seconds on 1100 machines uh back a decade ago now runs on my laptop in you know I think it's 50 seconds or something in ductb the last I tried it so a little over double the time sure but it's on my laptop instead of 1100 different machines right you know I think you know with motherduck we are trying to recognize that compute is changing, uh the processors are changing, memory is changing, all of these other dependent systems are changing and how do we change along with it. So we, you know, take advantage of the idea that duct DB can run in the browser and on your laptop and do something what we call dual execution. And it really like I I that's one of those areas where like I'm trying to focus less on the the technology itself and more on what that enables. So what that enables is if you go through like the motherduck web application and uh you type a query we can automatically preview the results of that query in in milliseconds without going up to the server because it's able to process that locally in the same duct DB engine as it would process in the cloud. So we really do believe in sort of joining the capabilities of your local machine with the capabilities in the cloud and just keeping it as simple as possible for users and for debugging and for you know frankly the infrastructure for us to maintain too. You know a big part of that is just saying yeah a query doesn't need to be processed by more than one machine in the vast majority of cases. You still need to be able to run tons of queries simultaneously and you want to be able to scale that and you know for that things like our hyperteny architecture where individual customers get their own dedicated uh you sorry your customers customers get their own dedicated duct DB instance for uh for example or every user of a internal data warehouse gets their own duct DB instance that can scale up or scale down
So there's things like that which which enable us to still scale out at tremendous tremendous scale without the complexity of you know being able to distribute each individual query across that many machines. Well that's great. So so this kind of innovative innovative architecture local first and cloud. So I want to kind of uh double click a little bit on you know this theme of extreme efficiency and ruthless kind of software engineering. So Hanus again talked about it at ID at Amsterdam and I think that also was in small data conferences that they engineer DB to be extremely efficient. So I think his example was like you throw a giant data set on it. It doesn't die it like slowly but surely chugs through it right like it doesn't blow up on joints and so it's you like there's a lot of work still ongoing at Doug DB right which is the research. So how much did that contribute to the success of DDB that it's very like resource efficient can operate in a very constrained environment like on old machines suddenly can be database servers how much did it contribute to the success of ductb >> it's a really really uh interesting question I think that like that that caused the origination of duct DB so in that way duct DB wouldn't be here if it wasn't for that like Hanis and Mark saw their their colleague colleagues who were scientists working at universities using things like you know the SAS and SPSS's of the world or using things like data frames and not using a real database as they call it um and you know they created duct DB for them they created duct DB to give those researchers a real database and it did start off as just this lightweight local library running inside our uh you at the time and then into Python
It's now the more popular. So that's the that's the origin story of duct DB. So in that way it's super critical in terms of kind of it it's wider adoption. You know it runs in Lambda functions there. Uh last year at small data SF you know we had uh the folks from Octa talking about how they run thousands and thousands of simultaneous duct DB engines in Lambda functions to transform their data. And you know lambda has pretty strict requirements from a resourcing perspective. So it enables things like that. You know for us really what what we saw in it is that innovation
I mean you attack you pick a technology for your data infrastructure based not only on where that technology is today but where you think that technology is going to go. And as as startup founders even more so right you know we're we're picking who are who are going to be our our partners in this world. uh for the decades to come. You know, duck DB was that for us because we saw the innovation with the ruthless focus on efficiency. We saw that they, you know, an academic paper would come out at a conference and a week or two later they would have that the results of that academic paper implemented in DuckDB. So new compression algorithms for instance some random researcher around the world would publish it and the duck DB folks would be like sweet this will make this faster and they pick it up and implement it and launch it and that is amazing for us. You know sometimes their innovation is so fast that that you know it keeps us on our toes because we then need to deploy it to our customers. That's that's why we're we're aligned with these folks and that's why our customers are aligned with us cuz they believe this is the direction for the future of of data analytics
>> I was just checking that uh mother doc was founded in 2022 in May and uh that means that it's a little bit prior to the big breakthrough with uh Chad GPT popularity and adoption. I mean people in the AI would would know before chat GPT 3 that something big is happening but for broader audience that's when it happened. So I assume uh like you said when you were starting startup you need to see uh what's ahead of you on a very long run to be successful. I think that the landscape changed quite a bit after this uh breakthrough. So I wanted to hear what's uh how that changed the strategy for mother duck anticipated one before that and what happened actually >> the VC landscaped and the financing landscape and and we were just very fortunate to have uh a lot of investors early on take take really big bets on us and give us the runway that we needed to to build mother duck as a service. Building data infrastructure takes a lot of time, takes a lot of focus. Um, you know, nowadays the the VC market is completely different. I have no idea what it would take to launch a company like Mother Duck in in the current VC environment
Um, because they're they're looking for these uh, you know, these bets. And there's some of these companies that, you know, are going from zero in revenue to like hund00 million in revenue in 9 months and like that. So sorry not not to swear at you but like there's some craziness going on in the AI world as it intersects the business world and VC financing world. So in that way I think we were lucky that we started before the AI wave. How does it affect us? I think actually it only it only helps us um and and why I say that is because you know data is at the heart of all AI. Uh there is no AI without data. there needs to be infrastructure uh to store data and uh AI needs access to that data in order to train and in order to execute. You know, I think what happened with with the LLMs is it it gave a renewed focus on data uh throughout the industries that we work with every day as as customers, as prospects
You know, it gave a renewed focus on them thinking, oh, data is important for us to be successful as a company. And you know, some things like the, you know, small language models give give the idea that, well, data is important, but highquality data is even more important because it allows you to build much more efficient models uh that take a lot less compute to train and to execute. And so, you know, I think it's only been benefited us. It has changed some of the conversation. I think you know in the first week actually that we kicked off Mother Duck uh in Seattle at the Madrona uh headquarters uh that was in June of 2022 where we all physically got together uh as the co-founding team. You know, I think in that first week we talked about, you know, the text to SQL and at that point there were a number of naysayers in the room, people that had spent a decade trying to make text to SQL work and it didn't really work uh using kind of traditional AI models. And now we're seeing changes there on the you know I you know we're still not at the point where text to SQL really works but we're seeing a lot of invancements that you know with the right schema and understanding of that schema with the right metadata around your data you know we're starting to be able to to take human language and convert it into results. There's still still a lot of things there like ARR means different things to different companies and different people within different companies like a lot of definitional challenges but it does create a whole new wave there where you know the ways that you're interacting with your data can change and and that's exciting to see and you know that includes LLMs you know we have we have customers who basically have LLMs answering questions uh using Mother Duck as as their data source and just generating tons and tons of SQL queries to find out their answers consumption based business those are very good customers for us to you know from that standpoint but also like it's building a better understanding of the data um and the you know if you can make the machine understand the data better and that helps the people understand the data better that's what we're looking for in business so >> this is great I I uh let's shift gears a little bit and talk about the rail right because uh small world I am now at uh Neo forj J the wonderful database company in the DL team and uh I found that Ryan was there before me and left amazing legacy and educational materials and everything and you know >> some broken bits >> and our you know by the way meetups uh we start we actually uh SF scholar was where mate is a career launched spark for the first time we spun off beer spark met up as the very first meetup in the world you know asked mate actually to start it right many years ago and so Then Ryan you wear de and data bricks right and so what really amazes me uh among like I've been to hundreds of meetups seen a bunch of companies I really like the de strategy of mother duck I think it's the most fun it's the most exciting so I just wonder how much is it nurture versus nature obviously duck db is an exciting product but you guys are throwing the funniest like most fun parties the side shows on the vendor events people come with the vendor pages to Duck DB dancers you know and get free old fashions of very high quality which I highly recommend of partaking
So like how do you come up with this? Is it decades of experience in DeL you know what really works you know to attract developers is it the magic like tell us how do you make this all happen? >> Uh first of all the question is is it devril or is it marketing? Uh and or does anyone care? You know, I'll give you a bit of a secret here is is when Jordan um you know, first asked me to to join him on this adventure of starting a company together. Uh this is Jordan as our CEO. I used to work with him at at Google BigQuery. You know, he was like, "Oh, okay. So, you want to you want to run Devril? Great. So, here's, you know," and I'm like, "Actually, nope. Uh I want to run marketing." Um and Devell is part of that. Sure
But like I want to run marketing and and it is my first role actually running marketing uh officially. Um if you ask the folks at Neo4j or some other places, I've been a Rebel marketer in the past. Uh people have regretted handing me the keys to Marquetto or to Salesforce um you know when they went away on vacation and I got myself in trouble. But in the end they were very thankful for it. And I think really what we're trying to do with marketing at at Mother Duck is take true empathy for the audience that we're trying to reach. You know, we have this audience of data engineers and data analysts and data scientists and AI folks and software engineers, product managers. This audience has a diverse set of skills, diverse set of interests and you know different reasons for living and why they you know why they go to work every day, what they're trying to do to advance their careers. I think a lot of other companies tend to to forget that uh and tend to kind of focus on the lowest common denominator or you know other way other cheat codes per se to make it easier
We try to take that you know empathy for that audience to heart and say you know what what would these people want right and uh they don't want another another company with a black or blue logo. They don't want another company just pitching at them. They want to have fun. They want to enjoy their jobs. Uh they want to learn new technologies and use those technologies to advance their careers. Uh that's really the approach that we take is we're just going to be like we're going to make this world not boring again. Um and that sometimes means putting the duck suit on. That sometimes means having like really fun swag and fun parties and uh then combine that obviously with great you know technical resources a great product behind it etc
But yeah it's really about bringing the fun fun back to data >> and thank you for doing that. I really enjoy all these parties and you know can't wait to go to more of those. So I am a little bit of scientist myself. So it's always an enjoyment for me to go to mother duck website because I know that the everything is styled with DAX and this is fun. But actually one thing that I kind of everyone knows about parties actually and DAX swag and everything but I really love this duck DB snippets website like a little separate website where you can either create your snippet and share that's like a little few lines of code that you share with the world or exchange and which does something uh like for example I open one right now and it says like quickly convert a CSV V2 to park a bash function. So everyone can go and copy this bash and just run them. So I think this is giving back to community. I really love that
>> So mother duck is a commercial product. Mother duck is not open- source itself. Um but you know we do really believe in the open-source ecosystem. We have this very unique business model where we went to Hanos and Mark and said hey we're trying to build this business. We know it is based off of your open- source technology. We don't want you to feel like we're abusing that open-source. We want to be good stewards of the community. So, they have a founding share of mother duck and we just kind of gave it to them for the be, you know, because we are using their technology
And then we also have a contracting relationship where where we pay them uh, you know, to help implement features which help Motherduct scale and things like that. But those features all go back to the open source world, right? So yes, we don't write open source code, but we spend plenty of money from our bank account to support the writing of open source code. And you know, things like the duck DB snippets site. It was actually originally inspired uh by what was the we actually took the thank you off because the the website that it was inspired by went under, but I think it was batch bashnstippets or something.com uh originally and it's just like give me like short little things that let me get my job done. Nowadays, uh yeah, maybe some of the AI tools, uh you know, Claude might might give a lot of these answers, but it needs to find it somewhere. So hopefully you know DuckDB place it finds it. Yeah. So but yeah we do like to give back
We you know the duct DB UI uh so if you just type duck db- ui uh that's built built we're slowly open sourcing some of those components to make that available. But you know meanwhile the tool is there for everyone to use regardless of whether using our commercial product or not. We also do have a free forever plan uh within within Motherduck that is part of our ethos is is really just help the help the community of data practitioners. Then they'll come to us when it when they're ready to come to us. Not everyone needs a new data warehouse every every minute or every hour or every day or every year. Um but you know within that seven-year time frame that most data warehouses last uh hopefully folks come and look at us uh based off of our participation in the community. That's great. I want to ask you know about this feature which really struck me is completely innovative like SQL is a you know 40 plus year old language
The second uh query language stand I saw is GQL which is nearjer took 40 years to do something like this and you guys came up with this instance SQL right feature. So you type SQL and it brings up results. Is it like the millennial kind of zoomer kind of thing like you want the media things showing up your own completion? How do you guys come up with this? It's it's real innovation in SQL world. Is it mother duck? Is it duck DB? Is it a collaboration? Uh like did customers ask for? How did it come about? >> Uh it really I think the background is in Hamilton the engineer uh on our team that created it uh who now leads our our UI team. Hamilton had has background as a as a music producer. uh he has a Grammy on his name uh as a music producer with that like he looked at all the you know music production environment what does he need to produce great music and he you know he calls it his flow state uh he needs to like just be kind of attached to the music and and I I I don't know the exact language that he uses to describe it but you know there can't be the delay because otherwise you get broken out of that flow so how do you stay in constant movement, constant iteration on your music. Uh the tools enable that like the and and so he took the ideas from a lot like the music synthesizer world and said how do we bring that to to data? Um, and so it really came from him. And before it probably just wouldn't have been possible without this sort of dual execution world where a powerful SQL engine can run on your computer that's the same SQL engine is running in the server uh server side
So, you know, essentially what it's doing is is pre-caching and such, you know, which has always been doable, but if you're pre-caching uh data using a completely different SQL syntax locally as remotely, like that just makes this a very difficult invention. You know, the dual execution made it a lot easier for Hamilton to to write this. You know, we hope to continue to expand that uh and get everyone into their flow state. This is amazing. Can we get Hamilton to like DJ at AI Bay? Is he available? >> I don't know if he still does that. Uh we we had Joe Reese at our big data London party. Uh so Joe Reese, the author of of uh the data engineering over and I think he had Carly Taylor with him and some other folks with them helping. There is a lot of music people in the data world
Uh but I don't know if Hamilton will will do live DJing. I can certainly ask. And maybe like the for the backs, you know, ground we can build like some SQL realtime SQL animations. Just an idea. >> Oh, we have we have a fun thing that we're playing with. You know, we're very into like the booth experience and the, you know, live uh live experience and how do you merge kind of the physical world that we're all in with databases and data? And so there's some fun things that we're playing with there. But in the meantime, have you seen the Duckify app? Duckify.ai. >> Not yet
>> Go take a look at duckify.ai. du c i fy.ai. This is another way we're trying to bring some fun to to data. You could take any picture there and duckify it. So, I already took a screenshot of us talking and maybe you can use this as your uh duckified version of this as one of your social images. But so, you know, we're we actually did that live at at Big Data London at our booth and printed photos out for people. Uh, and we're doing other things that kind of merge merge duck duck world and the real life. >> Nice
That's really good. Let's duckify it. >> Let's duckify it. That That's what we're trying to do with the world. Go get the duck and duckify it. And and the duck solves all problems. that that is actually, you know, the developer experience focus of of the DUTDB team is a huge part of of what I think makes duct DB a winning technology and that they don't like they're not about strict conformity. You'll notice that they've expanded the set of what SQL can do just to make it a little bit easier because it shouldn't always be about this standard that is 20, 40, whatever years old, right? like it should be about what allows people to get their job done and you know that's what they do and then they take that to things like CSV import the amount of time and energy they've put into CSV import >> is probably more than anyone else on the planet you know that is where you know how do you deal with there's one record amongst thousands that is off how do you handle that or someone threw a very weird delimiter in can you detect that or you know all sorts of things with regards to CSV or JSON or other imports and exports
Um, and so I don't know, maybe maybe we'll have uh SQL results duckified uh eventually. That's awesome. So I want to give out, you know, a secret like I know we we like we're all bound by an oath as professionals, but if I have your permission, I want to give out a secret into the world. Like a while ago, I figured out what a data lake is, and you can tell me if it's true or not. So I found out by random accident this big secret right that a data lake is just a bunch of CSV files in an S3 bucket. Is that true? >> Uh it fits my definition of data lake. Data lake is a is a central repository of data uh accessible usually via HTTP of some sort which is like the S3 protocol. Uh CSV that's fine
If it's parquet that's fine. iceberg or duck lake or you know hoodie or other things like that's fine most of those are just layers on top of parquet anyway uh I don't think it matters what the the format of the data is what matters is how understandable is that data how like the catalog how do you get access to the catalog what is what is the information that is out there and you know then and how much of a mess is all of that right so we went through the era of let's throw everything into the data lake and then you know the whole data swamp >> world came out uh and uh that's cuz people threw it in a bunch of unorganized ways into an S3 bucket and then they called that their data lake. Now a clean data lake has things better organized and a really clean data lake has a really great catalog on top of it and transactional support on top of it and then at some point you call that a lakehouse because it can you know serve as the same you know serve the same functionality as as a data warehouse. Although I would argue that a lot of lakehouses nowadays, you know, have can serve at high scale the same capabilities of a warehouse, but there is increased latency versus many warehouses. That is one of the things that we're doing differently at at Motherduck is we're we're look for sub-second latencies um you know sub sub even even you know a couple hundred milliseconds latencies on a lot of queries which allows serving different types of analytics applications than what a traditional data warehouse would do well uh when there's a an end user sitting and waiting for the result but lakeous kind of take it the other direction although you're seeing there was actually a duct DB extension released I I think today or yesterday by someone in the community that puts heavy caching in front of of a lakehouse uh type approach in order to you know give faster latencies with duct DB. But yeah so that yes data lake is just a collection of data in some bucket somewhere and then you know the utility comes on top of that. Yes. So this remind me I started as a joke but then you know every joke is a fraction of a joke
I remember another piece of Hanis's talk at P at Amsterdam where he talked about duck lake and I didn't go deep into this but I think what he showed was so here's how we do go about you know building a data lake you would basically have a bunch of tables and then you have bunch of metadata and if you run out of one you add another one and so there is another bunch of file but then if you delete data then you add a bunch of other metadata which basically to stones the previous data and then you can have a bunch have metadata showing what's actual current set of metadata governing the bunch of original files which have park files in the buckets right and so that basically becomes iceberg and then this is the part I didn't really get she showed a beautiful almost empty screen with like only two things in it has and this is the duck lake which is much simpler but I didn't get how is it simpler is there a better way to do this in this duck lake that thing what what's the simplification. >> The simplification is a a questioning of assumptions. So, iceberg had this assumption that as they as they were designing it that the data as well as the metadata should all be accessible over the wire without a server per se, right? With just using this blob storage that out there. So, we've had the separation of compute and storage. The idea is you should just be able to use that storage engine and access all of your data. No traditional database involved here. We've seen a resurgence of the the popularity of Postgress in particular as a transactional database in our industry and pretty much every single company is going to run at least one transactional database uh for their company and usually that is Postgress. So what Duck Lake said is is like, okay, there's all this overhead of interacting with these metadata files and layers on top of layers on top of layers of metadata files that you have to interact with in order to make a a query from like an iceberg uh data lake and or iceberg powered data lake or even a delta powered data lake
It doesn't matter. All of these have this assumption that you have these metadata layers uh whether they're avo files or JSON files, you have these metadata layers and and so that can result in like 80HTTP requests to you know do a simple update. Uh it's just inefficient and it's inefficient by design because they didn't want a traditional database you know involved. And so what ducklate does it just questions that assumption and says hey everyone's using Postgress anyway. Everyone's using a transactional database anyway. Why don't we store all that metadata in a transactional database and you know have I don't know 20 50 millisecond queries of all of our metadata you know a single SQL query being able to return the results of the metadata instead of 80 HTTP requests. It it really is just about like that questioning of the assumptions. It builds upon the same innovations that the iceberg folks did, that the Delta folks did
The idea that, you know, we can have a transactional database that is hosted in, you know, a blob store like S3. It builds upon that and then just says, well, let's just simplify that a bit more. Very similar to what like they did with DuckDB, uh, in terms of pairing things down and simplifying it. So that's why I'm excited about ducklake is is just it makes things easier. You know some people question the you know but this is just for duck db. It's actually it's an open standard. I think actually duck in the name confuses people a lot. You know the initial implementations uh it was created by the same people that created duck db
uh the reference implementation is with duct DB and with Postgress but you can use any database you want on both sides right like with whether you know any database for the compute of the of the data and any database for the transactional database that stores the metadata it's really about being an open standard and and making it not only easier on the consumers but also a lot easier on the people implementing it I think that you know Ducklake really came about because Hannis and Mark you know were trying to imple implement write support for for iceberg within duct DB and you know they're realizing how challenging it is to write another database in order to implement to implement write support for iceberg in duct DB and uh so they're still devoted to to doing that uh or dedicated to doing that and and they've they actually improved in the latest release a lot of the the iceberg support added write capability but then they said hey you know let's just simpl ify things a little bit for the future. >> That makes a lot of sense. Thank you for explaining this. Now I got it. If it's all a bunch of metadata that's probably reasonably sized, you can just shove it into a SQL database and it's structured already and just run SQL queries over it. >> It's like 1/100th this 1/1 100,000th the size or something on average. I mean it's a huge it's a tiny tiny percentage. And so some people are like well but the you know the relational database won't scale
Again, compute has changed a lot in the last 10, 20 years. Um, you can easily have pabyte scale, you know, data lakes backed by metadata that is, you know, much tinier than that in a in a Postgress database. >> Makes total sense really. Thank you for explaining that. That's pretty much all I had, Ollie. >> Yeah. Let's uh wrap up this episode. Thank you, Ryan, for coming and we hope to duckify B in November
All right. >> Go get the duck, everyone. Go get the duck. Thanks. >> Yeah. >> Thank you very much. See you soon in November.