Rockset | The Data-Driven Future

Hi, I'm Jerry Chen, partner of the Greylock and I'm here with Venkat co Founder CEO Rockset. Venkat, Rockset just raised her Series B from Sequoia and Greylock and we've been lucky enough to be investors from the seed round and the A round, which we both led with our friends at Sequoia. Tell us, what is Rockset? You say it's a real time database. What is that?

Thanks Yuri. It's been a pleasure working with you and Greylock. We are big fans of the firm and you, so thanks for your support and continued confidence in us and the company and the product. What is Rockset? Rockset is a real time cloud database built for modern data applications that needs to work at massive scale and with very little operational overhead.

Before we dive into Rockset and how it's built, you mentioned this modern data applications for the cloud. Give us some examples. What are these modern data apps and what are the problems you're facing today? Like, why aren't solutions today good enough?

Let me give you a couple of examples. So imagine you're a real time supply chain company that you're building a real time supply chain for, let's say, heavy construction and about 80% of concrete poured through the US are being tracked in your system and you're trying to build part of your application that needs to search across hundreds of different million job tickets that are flowing through your system. They're getting updated in real time using very modern cloud solutions like let's say, Amazon Dynamodb and whatnot, to be able to track and use it as a system of record. But there's a lot of parts of your real time supply chain application itself that are analytical, like searching through what's happening, what's leaving a particular job site and give a status update on things like that. And so how would you build something like that? You probably go set up an elasticsearch cluster, but then all of your data is being managed into Amazon Dynamodb. And so you start thinking about how do I in real time replicate all the data from Amazon Dynamo to elasticsearch and you start duct taping together a complex Rube Goldberg machine to be able to power what you want to power. And at that point you probably start searching the Internet and saying, is that a simpler way? Can I do it simpler? Another example is, let's say you have a very good data practice and you're like a leading hedge fund and you get data from hundreds of different sources every night you're munching through this and you use modern kind of snowflake and databricks and modern data stack in the cloud to munch through the data. But at the end of it you have like a multi terabyte data set that you really want to put it in the hands of every single analyst, every single investor in your company to make the best decisions that they can. These snowflake like systems are pretty fast, relatively speaking, so the queries come back in two to five seconds. But it's a very relative term, right? You want this to be subsecond and really, really fast. These are the kinds of applications that demand both speed and scale. The data sets are larger and expected interaction time for data that these applications are demanding are in sub second. When you pick speed and you pick a single node, MySQL Postgres or systems like Elasticsearch, you really compromise scale because the minute your data scale gets larger and larger, your operational complexity goes through the roof, right? And so there's a lot of cost and complexity that comes in there and invariably it becomes ridiculously expensive. I always say with enough trust, pigs can fly, but doesn't mean you should do that and doesn't mean it makes right sense. So you need to be building applications on a backend that is built for applications and not abuse your warehouse to power your applications.

I love that line. If with enough thrust, pigs can fly. And it's 2020 Venkat, so expect to see pigs flying out my window anytime now. You know, I have the saying that it's the right side of history, that the only thing that's inevitable in this world besides pigs flying maybe, is more data is going to be generated at higher rate, higher speed. So what you're describing, these modern data apps, is like you said, speed and scale, just faster data, faster response times. We're not talking about dashboards, we're talking actual applications. It's been a long time since I had to develop an application Vencat, but traditionally there are two types of databases, like OLAP databases for analytical workloads and OLTP databases like relational databases for operational workloads. Like you said, there's a trade off between speed with my OLTP databases and scale for my data warehouses. Help me understand why don't those two categories make sense anymore in this modern cloud data app world?

If you think about it, why doesn't it make sense is because transaction processing is very hard to scale. It is just fundamentally locks on top of locks on top of locks. I mean, it's just software wise, the requirement that the Technology has to keep up with is so demanding that it is very, very hard to give you transactional semantics and also make it scale. Warehouses are really storage optimized. They are not optimized to power applications. And there's a good reason, because you do need a system that can store petabytes of data and do occasional query processing every night. You're never going to not need that. Except that those kinds of systems are optimized for storage and not optimized for compute, which is what you need for an application backend.

Interesting. Totally makes sense. A data warehouse like Teradata Redshift for Snowflake can never power application because like you said, they're optimized for storage costs and queries that take one or two or three seconds. And you and I both know that if you had to wait like two or three seconds for your mobile app to load or web page to load, we would be on to the next thing. And then on the flip side, you're right. A relational database, which we know is really fast, was never meant to scale to the cloud, never meant to be these big data apps. So how do you break this kind of guns versus butter curve? If you think about Econ 101 guns versus butter, there's this speed and scale curve that these databases have to exist along. What was the inspiration to break this barrier, if you will?

One of our customers said that the speed thing you're talking about is like, look, if our internal tools are slower than Instagram, no one is going to use it. If it's going to take more than a second or two to load, you're just not going to interrogate with your data and make data driven decisions because it's too slow and you might ask for guess and it's faster. Guessing is faster. So that's kind of like the true inspiration that came is really we've seen this kind of movie before at Facebook and Google where we had a chance to be in the early days and hypergrowth years and build a massively scalable data systems. We saw the movement from batch to real time there. We saw the movement of the power of real time indexing, which is basically what powers Google Search and Facebook Newsfeed. If you look what is underneath the covers. And so we didn't invent this, we just saw a lot of this in the early days of what happened at Facebook firsthand because we helped build some of those systems in our past lives.

That's super interesting. I mean, you're right. If Google is basically a database for The Internet. And we all know how fast that is. You do a Google search and if that answers, respond in milliseconds, not a second milliseconds, I'm on to the next thing. If I search my Facebook news feed for a photo or a name, if that's not back in milliseconds, I'm on to the next thing. If you think about Google as a database for the Internet, really, that's inspired. And their secret sauce, like you said, is the index, the whole Internet. Facebook indexes your entire feed, the entire social graph. You have Rockset, then you say by that logic is inspired by Google infrastructure or Facebook infrastructure. The back end, where you guys worked at Facebook, the front end, it looks like a normal SQL database. You do joins and normal queries. It looks like a database, speaks like a database with SQL, but the back end looks more like Facebook or Google, which is super fascinating.

Google indexes the web and gives you a text box that you can type anything and it comes fast. We index your enterprise data in real time and give you a text box, except that in our text box you can type SQL. And that's really the best way to think about it. And so if you look at our backend architecture, the storage backend of Rockset really resembles a distributed search engine more than any other system in the world. Except the innovation comes in putting a distributed SQL query engine on top of that that understands how the data is indexed and speeds up any SQL query you throw at it out of the box without any administration or index maintenance and tuning and what have you out of the box. You point Rockset at your data, it indexes the data and turns it into fast SQL tables. And if you know SQL, you can build an app in a minute with Rockset.

A lot of the Rockset core engineering team came from Facebook. So maybe talk a little bit about this inspiration for what you saw at Facebook and how that led to the founding of Rockset.

Absolutely. Very blessed to work with some fantastic people that have built massively scalable data systems in our past lives. I was managing online data infrastructure myself from 2007, 2008 when Facebook had 3040 million monthly actives users, to 2015 when it scaled to about a billion and a half people. Our co founder Dhruba helped start the Hadoop file system project back in 2006 or something and really helped start the whole big data movement that happened. And then Dhruba also started the RocksDB project and every self respecting distributed database that have been created in the last decade or so. That is a testament to the quality of the work that this team has done. And Tutor is amazing. Tutor was the principal creator and founding engineer for the backend called Unicorn at Facebook. And all things search, from type ahead to post search to everything in Facebook is powered by the backend that he helped start and spearhead. And so yeah, I think there's a lot of massively scalable, really performant systems that we have had the chance of building and scaling in the past on a lot of those lessons and experience has definitely guided us. The biggest difference I would say between the systems, like let's say Unicorn or you take even Facebook Newsfeed, even Google Search, I would say they're all special purpose indexing systems. They are all built for powering one application. And that application is so demanding, it makes sense to build something very custom and scalable. The biggest innovation with Rockset is that putting a SQL layer on top instead of some custom, ad hoc, highly specialized newsfeed, runs one query, which is show me everything from my network that happened recently. It makes sense to have a system like this in this day and age, especially in the cloud.

That's interesting. The inspiration was this purpose built indexing for speed, for real time as you described from Facebook and Google. But at Rockset you took that kernel of idea and expanded to be a general purpose real time database. Maybe we can talk about these insights. I know there's three pillars I think about Rockset. There's this convergence indexing which we talked about before. There's this distributed SQL on top of it. So it is a general purpose database. And then what's probably undervalued out there, it's serverless, it's easy to use, easy to scale. You can scale compute up and down with a touch of a button, which basically gives your developer superpowers. So maybe talk to me about these three pillars.

Yeah, so this is a general purpose indexing kind of algorithm that we came up with. And the challenge is this, when real time streams are coming in, nobody can pause the world and say alter table, add column, blah. Because now my feed is now having this one more attribute. Now it has to just learn itself, learn the schema needs to be discovered on the fly and nobody can pass the world because a column change types or something like that. The converge indexing really allows us to index the data without knowing the shape of it ahead of time. The distributed query engine that you talked about is massively distributed. Every query, let's say you have a three way join on a massive data set in 1.2 milliseconds. Rockset parses the SQL, shreds that into fragments, which is little pieces that comprises that work that we have to do to run the SQL and actually schedules it on a distributed backend, which is actually an even driven reactive execution framework that is built in C for high performance. That whole thing happens in 1.2 milliseconds. And so the result of that and the serverless building, all of this to make it easy operational use, what happens is that you can basically say on a push of a button, say, scale the compute independent of the hot storage in which your indexes are stored. The aha moment a lot of our customers have, which is when they're like, oh my God, this is amazing is let's say they start up doing a POC, they're kicking the tires on, let's say a 16 CPU instance virtual instance in Rockset. And then they're like, well, the queries they take starting to get slower as I load more data. Well, I wonder what a 32 CPU instance would do. And then they push a button a couple of minutes later without failing any query live. It is now scaled up to 32 CPU and all of their queries instantly get to 2x faster. This is enabled by the distributed query engine because it runs everything, leveraging all the parallelism that is inherently available in the resources provisioned. And so that flexibility is only possible that we could give it in the cloud because we can spin up and the fluidity of the hardware is only available in the cloud. And so I think leveraging that to the fullest extent. Rockset is not cloud first or cloud native. We are cloud only. We cannot run anywhere else because we leverage the fluidity of compute and fluidity of storage in the cloud so much. That is why we were able to build a serverless solution with very little operational overhead.

I think Rockset is probably the first purely cloud native databases that were built architecturally to take advantage of the server compute disaggregation for speed and performance in the cloud. I talked to developers, I say to them, if you like indexing solutions like Elastic, you'll love Rockset. If you like SQL solutions like Presto or Druid, you, you'll love Rockset. If you like the ability to scale up compute and storage independently, like Snowflake, you're really going to love Rockset because you take a lot of those concepts around indexing in service SQL and compute storage disaggregation and you really take it to a whole nother level, if you will in terms of using those architectural insights from the previous generation, combining them all for this real time database. When we talk about this real time database, we keep talking about speed and scale. Give us some examples. What do you mean by speed and scale?

That I was talking about the real time supply chain at the earlier in the call and this customer came, they had hundreds of millions of records maintained actively in DynamoDB. They pointed Rockset at it and by day five they were able to build the search application that we're talking about. So in terms of speed here, the first thing that I'll say is developer velocity is how quickly they were able to take their new product to the market. And in their own words, Rockset took their six month roadmap and compressed it to a single afternoon. And let me talk about performance in terms of infrastructure speed. The hedge fund use case is also real, very happy customer of Rockset. They were actually building these web applications on top of Snowflake and they had two to five second queries and they looked at it and said like, hey, I don't need real time, but can your indexing tech make my web app faster? Because they had some dashboards where they were rendering 40, 50 graphs in a single page. And if everything takes two to five seconds, do the math. It's really, really slow. Definitely not faster than Instagram. So they came in, day one, they pointed Rockset at their data set. Everything got in a couple of hours, everything was set up. And when they did the performance evaluation, two second queries were completing in 97 milliseconds. So it was not two times faster, it was 20 times faster. Then we looked at it and we were like 97 milliseconds. That sounds slow because it was custom built for the kinds of applications that we envisioned always. We tweaked a couple of things by the second week. Their application now runs where the queries take 18 milliseconds, 1.8 milliseconds, 18 milliseconds out of the box, no tuning required. Your two second snowflake queries don't get and run in one second. If that's all we can do, you should continue to build apps. On Snowflake, it got 100 times faster. But here is the icing on the cake. Rockset was able to get that application 100 times faster with 1/4 the compute spend that they had on Snowflake. Because again, we're compute optimized. We are not faster than Snowflake because we can somehow magically scan huge volumes of terabytes of Data faster than them. We work very, very hard to never, ever do a scan. If we can get away without doing a scan, we're really compute optimized. We index your data, we just don't store your data. And we do that in real time. And that is where the power comes from. We're really compute optimized. Your applications will fly, your APIs will fly, and you don't have to do a lot of tuning and you can very, very quickly build your applications and scale in Rockset.

That's amazing. So it's milliseconds, not seconds. It's terabytes of data, multiple terabytes of data at scale and at speed. So if I'm a developer, why would I not use Rockset? So who are the kind of developers or customers that are a natural fit for Rockset versus either OLTP or even a data warehouse?

Great question. We are not a transaction processing system. So if you need transaction processing and you're keeping bank balances and you're maintaining inventory in a warehouse where you can sell one product is left and you can sell it to one person and not five people at the same time, you definitely need a system of record that has transactional capability. And that is not Rockset. If you have petabytes of data and you need nightly jobs doing reporting, you need a data lake, you need a warehouse. There's lots of good systems out there and Snowflake is a very, very good warehouse. Continue to use it as a warehouse. Especially when you have petabytes of data, you need something that is optimized for storage and not optimized for compute, because storage is the one that you're spending money all the time in those use cases and not compute. So you optimize storage and then you dynamically spin compute up and down for everything else that is Rockset. Because everything else is an application that is dealing with a lot of data. And you need to be able to build a system that is optimized for compute, because applications don't have an off button. And that's when you're spinning, burning compute all the time. The cost of the compute is going to be 10 to 100 times more expensive. And so that is really the sweet spot for Rockset. I think the world is moving more and more from batch to real time. And the minute you go to real time, you're not really building real time static dashboard. Every single one of those real time use cases is actually an application. And some applications are internal within your company that your product team uses. Your marketing team uses to make operational decisions every day. Some of those applications are even your end user, your end customer facing, but at the end of the day they're all applications which has no off button.

Venkat, can you give us some real life examples of these modern data apps? Take advantage of this speed scale ability of Rockset who are using Rockset right now?

The examples that we talked about like the real time supply chain company, it's commandalcon, it's our customer, we love them, they're great and they've been a big fan of Rockset and already using us in production. They are the ones that are indexing in real time. We also have Ritual, which is a e commerce company that sells multivitamins. Think of it as like dollar shave club for multivitamins. Huge fan of their product of the company. And the funny thing is Command Alcon was seriously considering elasticsearch and as soon as they saw Rockset they ditched it and came to us. And I don't think they're going to ever manage an elasticsearch cluster ever again for any of their applications. And Ritual is already a Snowflake customer and they really like Snowflake for the warehouse use cases and they really wanted to build a personalization engine for their e commerce experience for their customers on every interaction and every campaign that they want to run. And all of that is getting powered by Rockset.

We've seen this move towards real time from batch everywhere, stream processing technologies like Kafka, et cetera, those are all becoming kind of default parts of modern data stacks out there as well. Talk to me more about, where do you see Rockset fitting in this ecosystem of real time technologies?

That's a great question. So Rockset is probably the only sync you need to build any real time application from real time data acquisition technologies like let's say Kafka on one end of the spectrum and let's say things like segment on the other end of the spectrum and that is another popular source. It's more from the SaaS side that we love the company, we love what they do. Congrats to them for their recent acquisition. But that is another very, very popular real time source and we are the only sync that can keep up with the scale that they have in real time. And so we can power a lot of applications downstream where we are the serving tier for that real time data. I think Kafka is definitely kind of like spearheading this movement towards batch to real time. What Kafka really enables is for customers to acquire their Data in real time, putting it to work, answering questions very, very quickly on the data that you're acquiring. That's where we come in. I would say when you are acquiring a lot of data through Kafka, you have a Kafka topic. With a single click. Rockset will turn your Kafka topic into a fast SQL table in the cloud. We definitely, I think are a very, very good match and it's one of the most popular ways. Kafka and Kinesis in Amazon are very popular real time data sources that we work with already and we have managed connectors for both of them. We have a gold verified Kafka connector in Confluent Hub. Go check us out. So yeah, we definitely fit in this ecosystem in terms of stream processing. Rockset does not have anything built in. So we definitely expect some kind of a stream processing engine upstream from Rockset. But the output of your stream processing definitely need to be parked in a serving tier from which you're going to be serving your applications.

What about stream processing technology like Spark and the databricks ecosystem? You mentioned segment as collecting SaaS data, Kafka as another way to kind of collect your streaming data. And you have stream processing technologies like Spark and obviously Databricks as another kind of pseudo data warehouse out there. Do you see customers using you guys in that configuration as well in stream processing?

The way I think about it is it works really well when you have a preset data streams coming in and a preset set of questions that you always will need answers for. Instead of you running a nightly job and getting a report, you basically just say, let's say I need to maintain a whole bunch of bean counters. Anytime something happens and you have a bunch of dashboards and the counters just go up in real time. I think that use case is very big. There's a lot of companies that need that. And so stream processing is very, very useful. And that's their sweet spot. When you know the shape of the data and the exact questions that you want to ask on that data in real time. What Rockset is trying to disrupt is that unless your scale is massive, unless you're talking about tens of billions of rows per day, and you need to basically do processing on trillions of records, if you can get away with indexing the raw data and very efficiently answering the questions that you do have on the fly, the flexibility that you get out of the system if you include the human cost to your tco, because you always have more questions. When you have a bean counter, it suddenly goes up faster than you expect or goes down faster than you expect, or something changes. And you have now thousand questions on why. And a bean counter pre aggregated kind of system can never answer those questions. Right. And that's where the human cost is paid. So now every question I have, every hypothesis I have to test whether or not is that the reason why adoption or growth is going down or conversion are falling through the roof. And every one of those questions, let's say if it's 20 minutes away from you getting an answer, how quickly are you going to be able to get to the answer? How quickly do you start guessing and scrambling what's the lost opportunity there? And so those are the situations where Rockset is a completely game changer because this is not possible with any other system out there.

Got it. Okay. So we've talked about stream processing, we talked about Kafka, we talked about data warehouses and we talked about relational databases. There are some other categories that kind of look and smell like a database, but not really. Things like Elastic or Druid or Pinot. How does that fit in the ecosystem? And when would you use some like that and when would you use Rockset?

I think fundamentally, you know, if you take elasticsearch and Druid, they're all built for on prem world, they're not really built for the cloud. Right. So the biggest thing that we hear from our customers is the operational complexity for these systems. Right. And the minute you need one of these stack, get ready to hire an operations team and get ready to write performance reviews for them every six months. Right. And so that's the real big problem with these stack and they're not really built for the cloud and they're extremely complicated to operate and maintain. That's number one. And the second thing I'll say at the end of the day, both for elasticsearch and Apache Druid, it's true, which is they don't support SQL. If you again have a very stream processing type of a situation here where if you already know what questions you need ahead of time, then you can, you can denormalize data and do a bunch of these joins at right time as opposed to at query time, you can build your pipelines and data pipelines and all these things the other way, but there's no other system that gives you a fast SQL on fresh data out of the box. The lack of SQL also makes it very challenging to use these systems to power rich modern data applications.

That's great, Venkat, now that you're raised at Series B, what can your customers be expecting these developers the next year or two in the roadmap? I know there's a bunch of other technology improvements you guys are working on, but what's the near term roadmap coming out from the team at Rockset?

The biggest thing that we're working on and we'll announce soon and keep building out, make it better and better, is private VPC deployments. The big reason is that why is it important for a technology like Rockset is that if you use a data warehouse, a lot of the time the data you're sending to the warehouse is corporate data. It's the data owned by you as an enterprise. And you get to figure out whom to trust and who not to trust when you're building applications. Invariably a lot of the time our customers want to build applications on their end user data. And so there, I think the security perimeter, the compliance perimeter and all of that is very, very important. And so we are building this and announcing that Rockset is available in private VPC deployments where we have a clean separation of a data plane and a control plane. And so the data perimeter will be within your AWS VPC and will be fully contained and controlled by our customers, but we still have a control plane that at the infrastructure level will automate all the operations for them. And so it's really the best of both worlds where you get the low operational overhead and you get the flexibility and scalability of the cloud, but without having to compromise even a little bit on your security perimeter or security and compliance requirements. And so we can meet the highest standards for security and compliance while providing every single benefit of speed, scale and simplicity that Rockset offers for our customers. And probably in the coming years we'll even make that flow self service.

That's awesome. So the breaking the speed scale barrier, but on my own data, my own vpc.

Yes.

If I'm a developer or customer and want to learn more and get started, what's the best way to get going?

With Rockset, we launched self service since the very beginning. You can go to rockset.com set up a free trial, you get an automatic $300 credit and a two week period. And so you can go kick the tires, try all the things we talked about, resizing instances, and get a feel for query performance and scalability and all of that free of cost. And so no credit card required. And so it's a very, very simple thing to get started. And you can test with public data sets, if you have any not so sensitive data sets. That you can just point at Rockset. In a matter of minutes you should be able to get it up and running.

How do you charge a Rockset? Is it by Compute? By storage.

For our managed platform there's three components. You pay for every byte of data that is ingested. There's a cost, it's about $0.10 per gig of data coming in. And then there is hot storage which is how much data you are storing in the platform that is per gigabyte month. There is a fee then for compute. As I was talking about, we have virtual instances which are mini distributed compute clusters behind the scenes. That comes in a lot of sizes. It comes from all the way from 2 or 4 CPU virtual instances all the way to 512 or 1024 virtual CPUs. In a single virtual instance you can scale the compute based on your needs on query performance, query complexity, and the query qps and load that your application needs.

That's awesome. Once again, congratulations on raising the Series B Van Cat. Thanks for coming by the Greylock Gray Matter Studios and I look forward to our next conversation.

Thanks for hosting me, Jerry, and it's a pleasure. We have had a lot of fun working with you through these years and I look forward to a lot more years of working with Greylock, working with you. And thanks for hosting me in this podcast. It.