Let's talk about some of the business drivers behind why people are actually adopting NoSQL databases and I think that what's kind of interesting is that we kind of get lumped in with big data. What's interesting is I find that a lot of the actual problems that people are solving with NoSQL are not actually big data problems, so we're going to kind of focus on some of those. And it starts off with a bit of history. So in 1970, the gremlin was created, how many of you still drive a gremlin? Yeah, nobody. So this is the new American car. And at the same time, Ken Thompson, Dennis Ritchie were writing UNIX, or PDP-11. And how many of you actually still use UNIX, not Linux, but like actual UNIX? Nobody? Well, also in 1970, Ted Codd wrote a paper about a relational data model. Right? How many of you still use a relational database? I'd like to see more hands. It's amazing how long and successful the relational database has lived, right? It's just probably arguably the most successful software product ever, but it was originally created in 1970. And if we think about the problems that we were trying to solve in 1970, they were accounting problems. They didn't generalize it too much, but you look at every example in a lot of the early relational theory, you talked about payroll systems. The examples in the paper were like, how do I find all the employees that make above a certain amount or people that need a bonus? It was keeping track of inventory, keeping track of general ledgers and applications like this. And so it's no surprise that the relational model is a lot like a spreadsheet. Because it was sort of the problems we were trying to solve at the time, and there was a great analogy in the general ledger of how we actually kept track of tabular information. And so an RDBMS is like a spreadsheet, right? And it adds the notion of relations between rows, and this should be a review for everybody. This isn't new information, but what this means is that every time I need to create an association between two things, it involves me creating another table. Every time I need to refer to something that I might have many of, it requires me creating another table. And I create another table and another table, and pretty soon I have something that looks like this. I was talking to a gentleman at a conference a few weeks ago who was working on supply chain management software for his manufacturing company, and they had a relational database that had 60,000 tables. This is kind of an amazing diagram, because this is just sort of the highest resolution relational database design I could find at a quick Google image search. But you look at this as an engineer, I look at this and say, well, I have no idea what this thing is doing. I couldn't tell you what this application is. If you imagine being an alien dropping onto the planet Earth and discovering a magnetic tape with a relational database stored on it, you would have a really hard time reverse engineering what information was on that. This is a problem because as I start to try to solve more complex problems, I more and more end up with diagrams that look like this. This means that my engineers can't really pick up the system and evolve it quickly. It means that it's really difficult to figure out what an application is actually doing. This complexity slows us down. I like to use the analogy, I didn't come up with this, but I'd rather like it of a car. If you imagine trying to ask a relational database architect to design you a parking garage, your parking garage would be pretty odd. You're going to pull your car into the parking garage and the first thing the attendance can do is disassemble your car into all of its parts. I've got a bin over here for spark plugs and a bin over here for steering wheels and a bin over here for exhaust pipes. I might label all those parts with like this is car number 23, and that's the relations. When I want to get my car back, I go and reassemble all the parts based on that ID. It's a pain. You start to look at this, if all you see are all the parts, you lose concept to the fact that what I'm dealing with is a car in the first place. There's an enormous amount of complexity this creates in the business because it means that something that might be simple from a business requirement of like, I need to store cars, gets mired in complexity when the engineering team actually goes and has to build it and has to figure out like, well, how many different kinds of engines bike cars have?  No sequel is about leaving that car a car. Relational databases also run on fantastic machines like this. This is the IBM Z-Series mainframe. It's a cool computer. I would love to like have one. I, whatever, it's kind of fancy. It's got all kinds of like really neat engineering that went into it. Some product manager was really proud of the fact that I know I can install this without a raised floor. I'm sure he was running around with a spreadsheet for months trying to make sure that feature got into this release. But these are the kinds of machines I have to buy if I want to run a relational database at scale. This is expensive. This means it stops us from doing things that we might otherwise do. No sequel is more about, the way I think about it, it's about keeping things whole. It's about looking at problems top down. It's about thinking about a car as a car rather than the sum of all its individual parts. In many ways, the relational model is kind of like the assembly language of data programming. You're constantly working at the lowest level of the atoms of data and trying to reassemble very complex things out of it. One of the most interesting things we see about the evolution of no sequel is the ability to think about problems top down. This lets our software engineers go more quickly. Let's our business be more agile. We're going to walk through some of the examples of why this is the case. MetLife. MetLife has an enormous range of products and services. The problem they faced was that they had actually more than 70 different internal systems that had customer information. If you bought home insurance, you were in database one. If you bought car insurance, you were in database two. There was no database that linked all these things together. From a customer support standpoint, they actually have 26 different 1-800 numbers to call. You call this one if you want to ask a life insurance question and this one if you want to ask a health insurance question and this one if you're a brokerage trying to ask a question about something else. The rep that you're talking to is only linked in to one or two of those databases. If you call and ask a question about your life insurance and say there's a promotion going on that if you combine life insurance with home insurance, I'm going to give you a discount on your overall package, the support rep doesn't know that. Because they couldn't link all this data together, right? So they'd actually been spent, I mean they've been trying to integrate these systems for a long time at the point where my team came and talked to them, excuse me, they'd actually spent two years with a team of relational database architects trying to create one true schema of their customer and they were trying to merge these 70 different representations of what a customer was, what kind of fields do we need to know about somebody in order to make them a valid customer in our database and they couldn't, right, they couldn't, it wasn't that they couldn't like get all the systems integrated, it wasn't that they like didn't have enough time to write all the code, it was that the team was sitting there trying to figure out what is the set of fields that represents a customer and so what they were able to do and they used MongoDB to do this was they created a document schema that was more flexible, they could actually just merge in, you know, the 70 different products that you had bought by consolidating them all into a single document, there was a few fields that everybody agreed on, right, everybody has a social security number, well that's not true, but you get my point, there were a few common IDs that they could search on and then they could have this document that could contain sort of a list of all the changes that had happened across all of the product lines that this customer had and what this enabled them to do was to actually now create a single screen that their call center representative could look at and they could see all of the products and services you bought from MetLife, they could see all of the calls you had made to any of the support centers about any of the products you were using, right, and you think about this, the change that's meant for the business, you know, as a big company of this you're looking at like churn of your customer base, how many people are leaving you, what about your insurance carrier, like are you really loyal to who provides you car insurance, right, what are the things that like make you stick with MetLife or Amica or anybody else, right, and having a great customer support experience is one of the things that actually might make me stay somewhere because frankly it was one of the worst experiences of my life, I've ever tried to call a customer support anywhere. Craigslist, so Craigslist has, they actually keep track of every single post ever made to Craigslist, they do this for one for there's some features on the site that depend on this, like if you rent an apartment and you want to relist that apartment next year you can pull up the post that you had before and repost it, they also do it for like law enforcement purposes so that they can go and find people doing nefarious things and recall what was actually posted on Craigslist about it, but their problem was really needing to change that data model, there's an enormous amount of data there and what would happen is they would say hey you know what, it would be really great if you could search on apartment listings and find just the apartments that allowed me to keep pets in the apartment, so I'm going to add a field to my relational database, like allows pets and they used my SQL and they would log in like alter table, do a migration, add that column, it was three months before the prompt came back on their database to add that one boolean field of whether or not this apartment added allowed pets and what this meant was that they couldn't change their product line, they couldn't add a new feature. Can you say that again, that seems so long, I'm not sure. Yeah, three months, so I don't have an exact number, it is, I've got the, I can point you to the recording of Jeremy Zawadny giving that talk, and keep in mind that this was this was a database designed by Jeremy Zawadny who was the author of High Performance by SQL, great book by the way, but I mean there was, there's close to a petabyte of data, I don't want to, I don't want you to quote me on that, but there's an enormous amount of data in the archive, and so the problem was it took three months and then it replicated to the slaves and they took three months, think about the impediment that means to your business, right, like you now, they can't make changes to their product except for, you know, once a quarter, because every time they roll out a change that needs to change the database schema, they have to wait for a quarter before it's actually out there in production, right, so that ability to actually adapt and change is hampered if your database doesn't actually support this. Now they were able to move that archive in a schema, and so they can just start inserting new records that have this new field, that allows pets, right, the old records don't need to get changed, they didn't have that field, it's not really that important, and they can just start writing new records that have the new data, right, these are, again, some of these things that are very complicated in a relational database because of how much information you need to give the database about what information you want to store, you know, for MetLife it was the complexity of merging those 70 schemas together, for Craigslist it was the complexity of trying to add one new feature into that existing database, the Guardian, right, so if you're in newspaper today, you're probably pretty worried, right, you're probably thinking about, you know, am I going to survive, right, there's this massive implosion of the news business, so what do you do, right, you know, what the Guardian's trying to do is they want to become more agile, they want to try more experiments, they want to try personalizing the site, they want to change how news is syndicated, they want to change how you interact with with content, they want to play with different ways of making their content more interactive, right, instead of just broadcasting news to people, how do I carry on a conversation with my customers, and, you know, if you're one in the Guardian, you're probably thinking, I don't know exactly what that means, right, does that mean Facebook integration, does that mean comments, does that mean user submitted content, I don't know, I'm going to have to experiment, I'm going to have to change things really, really quickly, right, and part of the problem is, as you start to do this, as we adopt like agile development practices, say you know what, I'm going to divide up my 100% engineering team into 25 teams of four, and each one of them is going to go off and start exploring different functional areas and try to add features quickly to my application, like your DBA is going to go nuts, right, because that means you've got 25 different teams coming to you every week trying to say, can we add this column, can we change this index, can we, you know, add more table space to X, oh, we don't need that one anymore, it didn't work out, let's get rid of it, right, so your ability to actually innovate and add new features quickly and have that be a lightweight process, but this is critical to being able to evolve your business, right, you're not going to be able to do this, if you have a data platform that requires you to, you know, go through massive change in the database layer every time you want to add a new feature. So another aspect we see a lot of today is personalization, right, and you know, this is the probably could have pulled a bunch of examples here, but you think about what like Facebook and Twitter do, your feed, the thing you see on Facebook is completely unique to you. When you go to, when I go to Facebook, I see a totally different thing that you see, it's entirely based on who I follow and who I'm friends with. Telefonica, they have this system internally that's their personalization platform, it means I need to keep track of every single one of my customers. And in the case of Telefonica, they have people that subscribe to television services, they have people that have mobile phone service, they have people that, you know, watch TV online, use buy music tickets, whatever. And you think about the requirements to actually personalize the experience through any one of those services.  This is one where where I move from like in the in a content delivery standpoint, instead of having a set of information that scales, roughly with like the number of services I deliver or the number of channels of content that I'm actually delivering. Now I'm talking about having my data layer actually scale with the number of customers I have, and the number of interactions they have with me. Right? In marketing, you know, we stop dealing with like sort of segments of customers that these are like, you know, Gen Xers, and these are, you know, empty nesters and people like that. And you start dealing with the actual individual that's doing this interfacing with your business, right? This is a huge explosion of data. Right? And this means that I need to be able to keep data at the scale of all my individual customers rather than segments or channels. And it means I need to keep track of all the various interactions that people have across those channels. So telephonica that the problem they face was that they have a massive customer base across, you know, all the different products they sell. And they have lots of different things they need to keep track of like what television shows do you watch?  And to be able to ingest that information, store it and in a way that when you come to their website or use your mobile device or use your television, they can actually personalize that experience based on your preferences and usage. Right? First square is kind of an interesting application.  It's recommendation services. But I like I think about it, you think about it from a more broadly as a sensor network problem. Right?  I have tens of millions of devices that are reporting their location periodically. Right? I work with this guy, Matt, he's got like he checks in like 300 times a day. Not joking. And in order to be able to cope with that level of data, you think about like a business running a like a manufacturing plant, and I'm trying to keep sensors on all the machines and processes and keep track of what's going on inside of that plant. I mean, that that's that scale of information is like dwarfed by what a public consumer service like Foursquare needs to deal with in terms of the volume of location data that they're actually tracking all the time. So here, you know, the data sets here are not massive. It's not petabytes of data. But it's the volume that's challenging. It's that the fact that I've got tens of millions of users that are using this service constantly. And I've got many, many versions of my mobile app out in the world. Some people haven't updated the app. And since it was originally launched, some people have the one that was released next week, which means every check in might have totally different fields inside of it. Right?   Right? These are these are the types of problems that people are trying to solve with no sequel. These aren't always big data problems. These are data modeling problems. It's the complexity of the information, the complexity of the scheme of the rate of change of the information, the ability for the business to agilely cope with new requirements of the data that are coming in. We find like another one of the common themes is API driven applications. Right? So you know, I'm using parse as an example. They were just acquired by Facebook and they build a mobile platform as a service. I say if you're going to build a new mobile application, parse as a platform on top of which to do that, which means that from providing that back end, they need to be able to store the data from arbitrary new software that people build on top of their platform. So customer one might be, you know, building a check out, you know, mobile app to like, you know, pay at the cash register customer number two might building a music distribution application. You don't even know. But that application is going to define the types of data and things that it needs to store. It wasn't really challenging problem from a data modeling perspective because you don't ever get a chance to actually design a schema for any individual applications that are going to be running on your platform. You just have to cope with what data is there. If you think about another place, we see this a lot is on like financial markets, right? Where you have like the set of quotes coming off of the stock market. Right? What's interesting about that is that, you know, that data coming off of that that integration point is changing without you being able to be looped into that change. Right? You can't go to the like NASDAQ and say, hey, can you like let me know any time you're going to change the format. Maybe that's a bad example. You can't go to Twitter and say, can you let me know every time like the the twiddle Twitter feed is going to include a new field in tweets. Right? You just going to have to cope with that data as it comes. Right? These applications are being built to power mobile applications. They're being built to power REST APIs and web services. Right? And if you've ever tried to build, like take something like the Twitter API where what you're getting in is JSON data. This is what browsers and mobile devices and and even, you know, server to server communications are sort of standardizing on these days. If you ever tried to go and model those JSON documents as a relational table, it's kind of a nightmare. Right?  Right? You have a bunch of nested things that are related to each other that collectively represent a tweet. And it's really difficult to extract the actual entities from that. Right? And these are the things that that no SQL are good at. Right? These are cases where you have complex objects that are getting passed around. You have a high rate of change of what those objects are. Right? You have, you need to be agile. Right? And change your applications and product strategies quickly. Right? You have the need to to integrate with others through through APIs. You need to be able to handle things like sensor networks and personalization that involve high volumes of data that are coming constantly. Right? These are things that are relational databases are bad at. Right? They are not accounting problems in the classical sense. And you know what's interesting is you look at these types of problems and a few years ago you'd look at like who was tackling this problem. It was Google and Facebook and guys like this. Which is interesting today is the shift that that you know one of the most frequent questions I get asked by CIOs and CTOs are how do I structure my IT systems more like Google? Right? How do I, you know, should I be building out a private cloud? How do I, you know, be more agile? How do I, like I want to have mobile apps that power my business. These are not just things that new tech web companies do. We've got old school business. We've got real, real business, real businesses. Like Google is not a real business. But you know I picked out like MetLife and Goldman Sachs and ADP as examples that I know about.  Right? And these are difficult things to implement if you don't have a good platform to do it. Right? So I think that when we, when people talk about like oh why is no SQL popular and talk about oh it's like a big data problem. You use it when you have like petabytes of data. I think that kind of misses the point. Not everybody has a big data problem. A lot of people have business innovation problems. A lot of people have complex businesses and complex data that they need to be able to model. And a lot of the problem with relational databases and all the reason why these people come to non-relational databases is because it makes it easier to deal with that kind of change. It makes it eat so that you can actually deal with your business domain top down. You can deal with the actual entities that are flowing through and worry less about the details. And I like to close the sort of post transactional software development. Right? The music transaction, not in the like SQL transaction context, but in the like business transaction context. Right?  Right? And I think if you want to talk to those people and you have some level, what are the technology challenges you have today? Not one of them is going to talk to you about processing business transactions. Not one of them is going to tell you that actually like, how do I bill this many credit cards per day? That's not the problems they're worrying about. Right? They're worrying about personalization. They're worrying about how do I make better recommendations to my users to increase their uptake. Right? How do I move my business ahead more quickly? Right? If you want to be able to, you know, try to start an online e-commerce site, you're probably not not thinking about credit card processing or transaction processing as one of the core problems. Right? You sort of, these are largely solved problems. Right? You can go get off-the-shelf software that does this. The piece that's going to make your business different is all the things you do around it. Right? And so as we as we build this, I think there's this from Gartner Forrester. I'm sorry. Someone from Gartner Forrester is going to be upset with me because I can't identify which one. But they talk about systems of engagement. Right? Versus systems of record. Right? This is this is the scope of the relational database. Like, give me my customer list. Give me my list of transactions. But now all these systems that start to touch the outside world. Right? These systems of record, these are like these great bureaucracies, right, that we've built for ourselves where I can completely control every aspect of a transaction that goes on inside my business. I know the workflow exactly how this piece of information is going to flow to this other system and what rules everything is governed by. Right? But when you start to move out to talking to external systems, building applications that talk to mobile devices, that talk through APIs, that interact with your partners, that interact with your customers and your employees, these are these systems of engagement. They don't flow by the same rules. Right? Not everybody, you know, the way I use your website does not prescribe, you know, follow the the prescribed flow that you thought I would take. Right? I get to your I get to like product pages on Amazon and in very, you know, obscure and different ways. Right? And so my data systems need to be able to cope with that. And these are the types of systems that no SQL is very good at dealing with, not because the data is big, but because the entities I'm dealing with are more complex, the interactions I'm dealing with are more complex. Right? And so as we look at how we build software, right, we recognize that actually, you know, most of the software projects I'm building today probably don't resemble the software projects I was building 10, 20 years ago. Right? The challenges today are different. Right? And when you're looking at that, you know, you don't want to get stuck in the sort of false confidence of this this solution from many years ago, that works very well and works very well for a good domain of problems. You want to be thinking about what are the new types of problems that my business is trying to solve and how well does the database technology I'm using actually try to align with that. We're not agrees that no SQL is not so much an evolution out of big data. It's an evolution out of the type of software we're building. It's different. It's building different types of products that have different types of requirements that don't fit as well into that relational world. And that's the end of my slides. I think this, I never timed this, so I don't know how long that took. So, you know, in in Mongo or in any document or into database, you know, those entities are going to be represented typically as a single document. Right? So, you know, what tends to happen in the relational database, I have something as simple as like a customer. Right? And then my customer might have multiple mailing addresses. So now I've got a customer table and a mailing address table and some relationship between them and then customers by products and they might have different versions of those products. So I have some end-way association between a customer and which version of which product they had and things like that. And so what I end up with is one of those eye charts. Right? Because as I add more variance and multiplicity to all those relationships, I end up with more and more tables. But when you move to start thinking in a more document-oriented way, what you tend to do is you tend to start denormalizing that data and saying, you know what, I'm going to have a document per customer. And that document's going to have an embedded document that's like a list of products. It's going to have an embedded document that's a list of mailing addresses. It's going to have an embedded document that's a list of phone numbers. Right? And so what happens is that the document is much more self-describing. Right? And it's more self-contained. I don't need to go searching around through multiple tables in order to reconstruct this whole of what a user is. There's a lot of information that's lost in schema design. Right? Without that eye chart, if I were just giving the tables, I couldn't really tell you what the query was that reconstructed a user. I can see, I can sit there and follow all these relations and I could try to imagine, you know, the different variations of a user that I could reconstruct and give to you. The thing is, as a software developer, you have some representation in mind when you create a user. You kind of know that this is the version of what a user looks like that I want my applications to deal with. That's what I've designed to. And so in Mongo, you tend to still have that representation in there. It makes sense to you. So, you know, very materially, what it tends to happen also is that for that guy with 60,000 tables, right? What happens when you start to denormalize that is you end up with just fewer collections of things. Right? So maybe the 60,000 is a lot. So maybe that turns from 60,000 into 6,000. Right? Which would be a huge improvement, but still by no means great. But you see that kind of level of simplification happening when people start to think about their schemas differently. Right? You start to deal with a smaller number of more complex domain-specific objects. Right? And so your data model tends to be simpler. There tends to be fewer types of things with more variation within those types.  So I can totally see, but using Django, I'm still doing ORM, old school. And yeah, it's clunky. We all know that. So I can totally see the value of like having, you know, this document model and you know, stopping that into like a special table for this part of the application. But I wouldn't be inclined almost, I mean, naive and all, to just, you know, try this, try using the JSON field in Postgres and use that where specifically where it's appropriate. And the relational model specifically where it's appropriate and try to use just like one single database vendor. Yeah, and I'd encourage you to try. And I think that to me comes under a couple of things, right? So it's one aspect which is developer simplicity. So I'm going to be looking at it in terms of how productive am I when I use this database API? Right? I think that's my biggest criticism of the Postgres implementations. It feels kind of jacked on to that SQL language in a weird way. Oh, does lowly JSON feel JSON data type? Because it kind of happens like sort of stored functions that sort of parse the JSON and let you navigate it. They've done a good job. But still, as I as I go back and forth, obviously I'm biased. I'm not going to be like between the bottom. So using logo is sort of a breath of fresh air. This is so much simpler right for me to deal with than it is, you know, because even in I think in the Postgres implementation, I'm still sort of I'm embedding SQL inside of my Python code and that SQL has embedded within it to like JavaScript code that like deals with sort of procedures that access JSON objects. I've got like, you know, sort of turtles all the way down to the problem. It does not do that. It's a little easier to deal with. And you know, but I think that it brings up another interesting point, which is that that's not the only thing you would think about, right? Like like DB2, just add in support for longer to be wire portable. Great. Right? And start saying like, why? Because, you know, I want to worry about developer productivity. But I want these other things I need to be able to deal with also. How am I going to operate this thing? There's some ops team that has to have tooling and an ecosystem servers, you know, reporting systems and modern systems that can manage this thing, right? It's not just a database. It's a database management system. Right? And so, so as I look at like, you know, DB2 and MongoDB now are sort of both provide the same developer experience. Right? But they have very different operational characteristics to what they're capable of doing. Right? Mongo's still horizontally scalable source is anywhere. DB2 is obviously not, you know, as you look at, you know, there's a lot of value in the sort of skills of your team that a Postgres supports an API your team's productive with, and you've got experience running it in production, then it's going to be a good fit for you. You're not going to get some of the other things. Right? So, like in Mongo, you know, we have it's horizontally scalable. Postgres is not. Right?  But if you're going to need that horizontal scale eventually, then it might not be such a good choice. So, do you see MongoDB going and, you know, adding more, driven more in the traditional features, you know, like, like capacity for normalization or acid, blah, blah, blah? Some, yes, some no. I mean, I think the, the, the one of the things you'll hear over from MongoDB is that, you know, we don't think that arbitrarily complex joins or transactions scale very well. Right? So, you'll probably, you'll never see those in Mongo. There are some types of joins that can scale. So, for example, in, in like shard database, if I'm trying to perform a join, the thing that makes a join complex is the cases where all the pieces of the tables and try to join together are on different servers. Right? Because I ended up having to like have all these computers talk to each other, trying to coordinate, like, what is the, what is the set of objects on return? But, but all the things I'm trying to join together live on one shard, you can actually do that pretty easily. I wouldn't be surprised if in MongoDB you see some limited joint functionality where if I have two collections that are shard on the same key, right? And then I know that these things I'm joining together on one server, that we can make a scale. And that, that I think might be a reasonable feature for MongoDB. So, same thing with transactions. Right? And I think that all the, the guys at Toku and Max actually already added support for multi-stage transactions. With the limitation, it doesn't work in a shard environment. It only works on a replica set. And so, so I think you'll, you know, that, that's sort of one of the core principles that I don't think you'll ever see MongoDB. I want to make sure that, you know, we're not creating these, like, big, you know, hammers and guns pointed to your foot. Right? I wasn't using the comparison of, like, talking about, like, C++ developers. Right? So the first thing I hear when I talk to somebody using C++ in a project is, like, well, we use C++, but we don't use this feature. We use STL. We're not allowed to use this thing. And we don't use this core library. We have all these, like, principles to, like, to try to avoid the, like, mess that happens in, like, complex C++ programs. And you'll hear people, like, talking about relational databases saying, like, well, we use my SQL, but, like, we don't use joins. Like, it's all key value lookups. And, you know, you use all of these constraints within which you want to operate. And I think that's one of the, the things that is, is complex, makes software systems complicated is where they start to give you this functionality that you have to consciously not use because it has some negative effect on your production. So you want to try to create a system that's, like, sufficiently complex that you can solve your problems. But it doesn't give you these features that, like, oh, yeah, it does that, but don't. So, um, how does that answer the question? Yeah. I think I'd add to that the other thing that we get asked about a lot are, um, these things like, like, when are you going to support an ODBC driver? Right. And so a lot of people are trying to build an ODBC driver to talk to on relational databases. And, you know, that, that's an area where I think you lose a lot in the transition. But the things that are really hard to make at ODBC are the, the dynamic schemes. Like, most, most visualization reporting tools when you have my friends here, you know, you need to know something about the data you're trying to visualize. Right?  I need to know what fields are there. Right? And so the challenge is, I don't, I don't, it's not really the protocol. It's just, you know, there's, there's, there needs to be new visualization tools that can better cope with dynamic schemas. Right? Similarly, like, one of the, one of the biggest things we worry about with ODBC is that, you know, it sort of naturally is a table-oriented representation of data. Right? And so that, that, if you were to, if I were to give you a ODBC driver, you'd be highly likely to start building what's essentially a relational schema and building your application that way. And, and what ends up happening is like, yeah, like, like, don't do that on a wrong way.  You're gonna have a really bad time. Like, use my C14. You want to use a ODBC if you have a relational data model and want to represent things as tables and relations. Like, use a relational database. It's better if that's what you're trying to do. Right? If you're trying to do that in a long-term way, don't have joins. We don't have transactions.  It's gonna be really frustrating. So, like, the notion that, that we need to, like, take it after, like, what we fear is that people are just gonna take an arbitrary piece of software, like, oh, here's a share point that uses, like, ODBC. Like, let me just try to slap a document database behind it. It's gonna be terrible. Got it? Got it? Okay. I guess we're done? Thanks? Alright. Thank you. Thank you. Bye. Bye. Bye. Bye. Bye. Bye. Bye.