 Now, talk a little bit about why you're here, the whole big data trend and what that means to Tokutek. Sure. So, the big data trend is obviously one that's gathering a lot of interest from customers and the way we view it is what's the necessity behind all the invention that's going on in the database world right now? You see a lot of no-sequel opportunities, you see a lot of warehousing opportunities. Recently Vertica was acquired by HP. So if you step back and look at what's driving all this appetite for data processing, you notice this kind of strange distribution of where technologies are delivering products that work. One is around OLAP technologies and the other is around OLTP technologies. But that doesn't really match what websites want. Big Web 2.0 properties with lots of traffic and complex applications want to blend of real-time analytics and that combination of transactions and real-time and analytics in the OLAP sense creates a real problem for MySQL and other databases using conventional technologies. So we address that. We say you can have both. You can have your real-time processing and you can do analytics against it. And that's the nature of the technology that our founders came up with. So the problem we talked about earlier today in this event is a scaling problem, is that correct? It's a huge scaling problem because people find that as they grow their business applications usually with MySQL and NODB, they reach a point where they're trying to insert into those databases and query against them, but they can't anymore because they're too big. So that's the big data. That's the scalability problem. And then what do they do? They can partition their data. They can start looking at other products from Oracle and so forth or they can go in the no-SQL direction to try to get their arms around the data processing. But at the end of the day, what they want to do is more of what they had been doing and we let them scale out in that direction in a way they can't before. Okay. So you provide sort of an incremental path to specifically MySQL, correct? That's right. The current version of the product is designed from MySQL. The underlying technology will work on any database platform, but that's the first one that we're commercializing. So this is kind of the case where a client doesn't have to rip and replace and completely bring in new skill sets. You're allowing an extension to their existing infrastructure, their existing processes. How far can you take it? Can you actually sort of compete in the realm of where Hadoop is going or is that more further off for you guys? Well, I don't want to say that we're head-to-head with Hadoop. One of the great things about being in this industry is that there's a lot of innovation with a lot of different tools and I'm sure that there are workloads for which Hadoop is exactly the right solution and a relational database would be the wrong solution. But for many people who feel backed into using Hadoop because the relational databases have failed them, we're the right solution for those folks. And in terms of scalability, we have one customer who has purchased a license for six terabytes. So in terms of scaling out MySQL into much, much larger deployments than people are used to thinking about, we're working great. Yeah. You know, we talk a lot about big data, but really the issue is data, right? So my big data might not be your big data. We heard at Strata a couple of weeks ago, the Strata conference, the O'Reilly Media Strata conference on making data work, that a lot of times things like Hadoop are overkill that we can actually do a lot with the tools that we have. Is that what you're seeing in your customer base? Yes. And get back to your earlier point, there's a lot of specialized expertise that customers would have to acquire, either grow it themselves or hire the people with Hadoop expertise and expertise in these other new technologies that isn't as widespread. And since we're on MySQL storage engine, it makes it very simple for people to just drop in our storage engine without changing any of their application logic and MySQL code and be productive right away. So talk a little bit about your secret sauce. It's this MySQL storage engine that you've invented and have now productized. Talk a little bit about what it does, what's out there that's like it? Sure. So it all comes down to indexing. And the notion in computer science about indexing is that if you need to find a piece of information more than once, you're smart to index it, which is a way of finding it quickly. If you don't index it, you have to scan your entire data set to find it again. So if you have a phone book, which is alphabetized, you can find a phone number by name trivially. And if you have to find it by first name, you can't do it without scanning the entire phone book. That's what an index is. Indexing was innovated in the 1970s with a data structure called a B-tree. We've got a better data structure and a better algorithm than the B-tree because 200x faster. So better as in, yeah, faster, it's more efficient and more scalable, presumably. Absolutely. Two major wins with our data structure. One is that it's 200x faster for adding data into the database. So that relieves this problem with big websites facing a huge onslaught of data. And two, the data structure does not fragment. The big problem with B-trees is that after a while, after you insert into them, you have to do a dump reload to get your query performance back up where you want it to be. This data structure that we've developed doesn't have that property. And so you can run it continuously without taking your database down at...