 Hi everybody, we're back. This is Dave Vellante at Wikibon.org and this is theCUBE's SiliconANGLE's continuous coverage of the O'Reilly Media Stratoconference Live from Santa Clara, California. We have a great guest coming on. Somebody who's been in this business for quite some time, Bradford Stevens is the CEO and founder of Drawn to Scale and my colleague, David Fleurer, is back. Bradford, welcome to theCUBE. Thank you so much. It's a real pleasure, guys. Yeah, it's nice to meet you and good to have you here. So this is, let's see, our third Santa Clara strata, I think our fifth or sixth strata plus a Duke world that they've merged in. So we've been watching this for quite some time now. You were mentioning off camera that you've been at this since the beginning, one of the early Hadoop practitioners. So come quite a ways here. Yeah, I was lucky enough to be asked to help organize this conference from the beginning back when we didn't really know what big data was and perhaps today still a lot of us don't know. And it certainly changed a lot. I can tell you as sort of somebody who was traditionally moved from hacker to engineer to CEO, it's really been an interesting growth at this in terms of both revenue and size, like just the sheer amount of lack of a better term, I guess, energy that is both coming from the conference and just if you walked around the Exville Hall, the amazing amount of cash people are pouring into their big data problems. I haven't seen anything like it, I guess, since the cloud days. Yeah, I mean, actually you're talking about the practitioners pouring cash in. We were seeing deals, numerous deals, over $50 million, $100 million deals going on, not just from three letter government agencies. I mean, it's really started to get pretty serious. And I think that talks to the value propositions and the productivity impacts that you can have. So how does drawn to scale play into that whole thing? You're seeing some really strong themes around SQL and Hadoop. You're seeing the platform wars around the distros. Still a lack of great apps. Exactly. But let's talk about all those things. So start with sort of drawn to scales, participation and angle. Sure. So you may have noticed, and this called even us by surprise, I didn't think it would have moved this quickly, but this seems to be the year of SQL on Hadoop. Everybody has a SQL something on Hadoop. Which is pretty cool. And there's a lot of different things. There's people with SQL interfaces to map reduce, like Hive. There's folks like Green Plum and Claderism Pala, which are data warehouses meant for internal facing analytical applications. And I think you've noticed there's now nine or 12 or 15 different distributions in data warehouses. And it's very, very crowded. What we're focusing on at drawn to scale is solving the key problem you mentioned of there's no apps on top of Hadoop. I can't take my legacy ERP platform and copy and paste that onto Hadoop. That doesn't make sense. I can't take my website and run it on top of Hadoop scale data. There's no database there. And databases are what everything is built on top of. So we have built Spire, which is the first application database for Hadoop. We're not really focused on analytics. That's, it's a pretty solved problem. And we're going to leave that to the guys at Green Plum and Teradata and Oracle. What we're focused on is being an application database. Transactions, hundreds of thousands of reads and writes a second, full SQL support. You know, something that you would build a social network on, your telephone call management system on, things about high volume and real revenue generating user facing applications. So how did you decide that this is what you wanted to build? You said, you know, today there's all this buzz around SQL and Hadoop. And what you must love, did you predict it? Did you just have a passion for it? Did you see a problem that needed to be solved? Tell us how you, you, you take us back to the beginning. When you said, I'm doing this. Our marketing copy would be better had I predicted this. I've, I mean, you know, a little bit about me. I grew up in Amish, Pennsylvania, like writing software on my 386 when I was eight years old. And for some reason I've always loved crazy, complex stuff. And there's really nothing more complex than a database. And I started my career at Microsoft and worked on SQL server there. And the thing I saw at Microsoft and, you know, for the next several years of my career is that when something breaks, it's always the database. When engineers complain they can't build some new feature that's really important. It's because the database is crashing or it's because, yeah, the stand. And really when you put too much data in a traditional database, it just falls apart. So around 2009, I said, all right, Google has solved this problem. Google has the unified platform that can hold petabytes of data and everybody at Google writes their software on this one huge giant database. At the time it's Bigtable, now it's Megastore and F1. And then I looked at Hadoop and HBase and said, Hadoop is a great tape drive. You know, I can, I can batch process my data in it. This is cool. And then we've got HBase, which is great if I have a background in distributed systems and understand what ones and zeros I need to place where. But SQL is the Rosetta stone for data. Why can't I have a SQL database with the scale of Hadoop and HBase that the average Rails programmer can just write an app on top of and suddenly scale to petabytes of data in a period of milliseconds. It's very difficult and to do that you have to build something from the ground up but I think that's where the real value is. So you're competing in the space with people like Couchbase or Aerospike or MySQL, trusted MySQL. Exactly. So why do you think something different was needed? Another instantiation of MySQL is pretty well known. So there's two key things, sort of two converging industries that were sort of happened upon. You mentioned there's the distributed NoSQL stores and NoSQL in some ways is like no features, no understandability by developers. Aerospike is great, Cassandra is cool, HBase is a NoSQL store but the average developer can't write code against it. There's no SQL. If I want to do something really simple like, I want to know who my top 10 customers were last month there's not really a way to do that without writing a whole bunch of custom code on top of it. And likewise, if we look at things like MySQL cluster, even to an extent Oracle Rack, operating a MySQL cluster at the dozens of terabytes, the petabyte scale, is practically a business of itself. And when you go to a distributed MySQL, what you don't learn right away is that you throw away much of SQL. You can't do joins very easily in distributed MySQL. You know, doing group buys or filtering out data becomes this huge difficult task because of the distributed nature of things. In a lot of cases, and something we've seen with our customers is that they come to us from MySQL cluster where every query is running on every single machine in that box every time. And if you're doing something on like a Facebook scale or if you're a telecom and you're trying to do, trying to record all the records from your telephone calls, you can't have a system where every query hits every box every time. It's just, the way databases were built 30 years ago, which is how MySQL, which is how Postgres are architected, this isn't compatible with the distributed world. So, you said you were sort of Bradford joking about your marketing copy, but this is a great page on your website, who we're for, and it lays it out, you know? Thank you. You want real time, you want rich query, you got an HBase, but you don't want rich queries. You want scale, you got scales, but you can't leverage them, and that's really what you guys are all about. Talk about some of the use cases that your customers are pushing you towards. I mean, for instance, is ad serving one? Is that, I mean, clearly would be an obvious one, others that you can talk about? Yeah, so we'll start. I think there's three big use cases and verticals that we're seeing. The first is web apps and mobile apps. You know, I'd have millions of people accessing this application on my phone. One of our public customers, Flurry, does this. You know, I have millions of people accessing information from my phone, like I open my Angry Birds app and throw a bird, how many points do I have left? All that stuff. That's all backed by a giant database somewhere. Flurry is one of the largest HBase users. They have two petabytes of data. And what they said is, you know, we need a way for developers to write mobile apps that use SQL and don't have to worry about the data backend. It just needs to scale as they have more and more users. That's really where we shine. By being a SQL database, there are customers who are developers know how to use this. And by scaling to be really large in real time, there folks can concentrate on writing mobile apps and not being database experts. So web and mobile apps is a big one. Another big one you said is, we're doing something with a large finance company on sort of a take on advertising serving. It's a real time recommendation engine. And it's really cool. I usually have some prop to tell this story with because I have it so many times, but imagine I go to the Apple store and buy an iPhone with and buy an iPhone with my card. That transaction has been recorded in the say, hey, you just bought an iPhone. Next door to you is an accessory store. Why don't you go next door, use that same credit card and get 20% off an iPhone case. So you can imagine these guys, they don't want to be a payment gateway anymore. They want to control commerce from end to end. And as you can imagine, filtering through hundreds of thousands of credit card swipes a minute to return recommendations in a few seconds is not an easy task. You need a giant database just to handle that volume of data. Yeah, people talk about real time or in time data. I like David Floyd's definition the best, especially in this use case, is real time is before you lose the customer. Yeah, customer time, human time. And there's so much noise around what is real time today. And even I feel guilty as an engineer for abusing it. For us real time, we think of as a few hundred milliseconds or before somebody thinks something is broken or before they leave the website. A lot of other folks, if you've probably seen with the vendors, with Impala, with the new green plum thing, they think of real time as an analyst gets his answer in three seconds to a few minutes. That's an entirely different kind of real time. That's fantastic for analytics. We think of it more in terms of, you know, web scale real time. Okay, so we had web apps and mobile apps ad serving sort of a derivative of that. There was a third? Yeah, a lot of stuff going on in telecom, which is surprising, because they've always had big data needs and they've always been terrified of using anything that's not Oracle or DB2. So one of our customers who was a huge telecom out in Europe said, we want to be a data company. We have so much amazing data. And right now, you've probably seen this, if you log into your Verizon billing statement, that's maybe updated once a month. Like everything in the telecom world is actually giant batch processes. And when you're a customer service rep there trying to diagnose a problem, or you're a business user trying to see how many people are making calls from which departments and all that, you can't actually do that because that information is scattered across 50 different Oracle databases across Europe. So what we're doing in a telecom field with the several customers is saying, hey, we need a database that scales that we can put all of our data into one place for because we want to build better customer service apps. We want to do better diagnostics. We want to do predictions. So if there's a soccer tournament in Nice, France, we want to know how many cell phone towers to build to support that. And traditionally they would have to go get an analytics team together, query 20 different databases, and then make some kind of decision. But with our database spire, they're able to update all that data in real time, look at the usage in real time, and build applications on top of that so they can make those predictions so that they can manage their company better. So one of the things that I've been talking about is the migration from the traditional transactional system which then puts all its data onto disk and then weeks or later you get it back again to combining transactional and analytics essentially in one pass through the data and then making sure the metadata is held in active memory. So is that the sort of model that you think is coming and that's a huge change in the marketplace. What are the steps that you think you can do to use Oracle, for example, from its primary position in the current stack? I don't want to say I'm usurping Oracle in any way because they have way more much money than us and I don't want to get crushed yet. But what we're seeing is, and we've seen this at several of our, especially customers in the telecom field, they're being told can you stop spending so much money on Oracle, we're not getting out of it what we need to, it's not letting us scale, we feel really locked in. And to your point, people, especially at these larger organizations, data is siloed into lots of different OLAP and transactional databases. And so when you need to update information or make a decision or build an application, you may have to pull from 10 different databases. And the reason why in the first place there are different OLAP and transaction databases is traditionally we've had to have the one giant mainframe that has a database for a single purpose. But in a world where everything is distributed, you don't need to custom build super high efficiency transactional and analytical engines because if I can have something more general purpose that's 5% slower, I'll just buy 5% more machines. And so what we're seeing is this sort of convergence of this used to be transactional, this used to be analytical, and instead we want to put this data in one place so that we can build apps on top of it so our analysts can see what it is and not have to wait months to get all the data into one place. And I think it's going to be a huge shift and it's because we're starting to build things to be distributed from the ground up. Brad, for great perspectives, we're out of time, but thank you very much for joining us on theCUBE. Thank you so much. It's a pleasure to meet you and I'd love to have you back sometime. Absolutely. And thank you, Brad Samora. All right, and thank you, David Floyer, for sitting in. Keep it right there. We'll be right back with our next guest. I believe Ed Dumbill is up next and we're going to wrap up the show. We've got a few more guests. Pauline Nist is coming on as well from Intel, so keep it right there. We'll be right back. This is theCUBE from SiliconANGLE from Strata in Santa Clara. Right back.