The $9B Startup Going After Snowflake and Databricks | Renen Hallak from VAST Data

Sure. So VAST Data, we built a data platform. Not surprising. We started from storage. We built a new type of storage system that allows us to store very large amounts of information and have very fast access to them. And then we added database functionality. We're adding compute functionality, basically trying to be that middle of the sandwich, taking advantage of the latest and greatest in hardware underneath us and to give applications the easiest APIs on top of us.

Yeah. Revenue: we've sold more than $1 billion worth of software so far in the last few years. Growth: 5 to 3x year over year. Efficiency: profitable five years now.

Yeah, we started in 2016. It took us about three years.

Yeah, it seems like a long time, eight years into it, but we're just getting started. We went out of stealth in 2019, but we only exposed a small portion of the vision back then. We talked about universal storage, not about the full data platform. And then last year, like you said, second half of the year, we opened it up to the world and talked about what we're really about.

I think so. The world is moving from numbers to pictures and video and sound and unstructured data more broadly: genomes, natural language. And we've built a platform that grows into exabyte scale. The world is moving from CPUs analyzing data to GPUs that are a lot hungrier for information. And we built a platform that provides very fast access to all of this data. And so from day one, that was our North Star, and we've been building towards this revolution.

So, interesting story. I was at a company called EMC before. I was acquired into EMC through a company called XtremIO. I was head of engineering there, and I felt like they didn't need me anymore. Sales were going well. We hit $3 billion in two years as part of EMC, of course. And I felt like we needed to build something new in order to address challenges that were coming in large-scale analytics and AI. I felt a new architecture was required, and building something new within EMC was practically impossible.

And so I left, and that's how VAST got started. In the very early days, it was just me, but very quickly we assembled a really, really good team of co-founders around me.

A bunch of very good architects and developers: Alon, Asaf, Avi. As you can tell, Israeli names. I was back in Israel at the time. And then a really good R&D manager, Shahar, who kicked me out of Israel and said, "Go sell this so that people can actually use it." And that's why I moved here to New York. And Jeff Denworth was our first go-to-market guy. He was a one-man go-to-market army in those early days.

That's exactly right.

750.

So R&D is more than half the company. And even within the go-to-market teams, I would say more than half the people are sales engineers and technical people. It's a very engineering-heavy company. But yeah, R&D is mainly out of Israel, and everything else is here in the U.S.

It's a few things. The first one is that it was very clear back then that old ideas, old algorithms, are starting to have value. And again, eight years ago, it was finding cats on YouTube videos. It wasn't yet generative AI or large language models, but it was already clear that fast access to a lot of information is the key to generating benefit from these algorithms. And we wanted to enable that. We wanted to enable that for everyone else. Obviously, Google knows how to build it for themselves.

There are a handful of companies who do, but everybody else needs someone to do it for them. And so we started by breaking those fundamental trade-offs that have existed in the storage space for so many years. And then we realized that in order to do that, we need a new architecture. And that new architecture enabled us to break those trade-offs, not just for storage, but for the entire stack. And so I think our biggest advantage versus those other companies that you mentioned is that we started late, and that allowed us to see this deep learning problem in front of our eyes versus machine learning.

Again, a lot smaller, a lot slower. And it also allowed us to leverage underlying parts that didn't exist before we started. And so starting late is our biggest advantage.

Yes.

I think Peter Thiel says, in chess, first mover gets a third of a pawn advantage or a quarter of a pawn. Last mover wins the game. We want to be last mover.

Yes.

The architecture, we call it disaggregated shared everything. And that is basically what we try to do, is break the fundamental trade-offs that have existed in infrastructure between price and performance and scale and resilience and ease of use. And we thought if we can build one system that's faster than the fastest was before, and cheaper than the cheapest was before, and way more scalable, way more resilient, and that manages itself, then that's a solved problem. You don't need to think about that piece anymore, and you can focus on your application.

And so in order to do that, we had to come up with this architecture.

We tried to, yes, collapse that pyramid because historically it was relatively easy to say, this is two days old, I need fast access to it. Now I'm moving it down to a midrange system. It's two weeks old now. It's two months old. I'm never going to touch it again. I can put it in an archive. But AI doesn't conform to that model. You need fast access to everything in order to build an AI model. And once you have it, you want to infer on everything to generate value out of it.

And it turns into this loop of random reads over and over and over again. And so you want a new system that enables these new workloads.

We don't want a machine learning engineer to think about infrastructure. The three words that we get back most often from customers, and that we love to hear, are, "It just works." And, yeah, infrastructure is like plumbing. If you don't notice it, it means it's doing a good job. And you need to focus on where you bring value and let us worry about everything underneath.

Sure. So every scale-out system that I am aware of before VAST is based, loosely speaking, on a concept called shared-nothing sharding. You have a lot of nodes in a cluster, and each one of them has direct access to a bit of the namespace, and each one of them has responsibility for a piece of the pie, for a piece of that namespace. And we realized that that architecture is reaching the end of its rope. It starts to see diminishing returns in performance as you scale beyond a certain limit.

Resilience is very problematic. If a node fails, you need to recover that node's responsibility, and it can take a week. And during that time, you can't have another failure. And so that limits the scale of it. What we needed to do is the opposite. Instead of direct-attached, having drives in the nodes, we disaggregate. We put the drives on one side of the network, we put the logic on the other side, and we leverage a new protocol called NVMe over Fabrics to make it look like all of those drives are directly attached.

That allows us to scale capacity independently from performance. It allows us to scale with dissimilar parts over time. So you never have to migrate your data between systems. More importantly, it allows us to move from shared-nothing sharding to shared everything. Every node can now see the entirety of the dataset: data on low-cost flash, metadata on storage-class memory, all on the other side of the network, such that they become stateless and they don't need to talk to each other anymore.

And so now you have the most resilient, the most performant, the most scalable architecture. And then we added a lot of algorithms and metadata structures on top to solve the cost equation and to make it efficient.

Yeah, it turns out that this architecture is really good for storage. But once we solved the storage problem, our customers asked us for more. They said, couldn't you use this same architecture and break the fundamental trade-offs that exist at the database layer and at the compute layer? And can you build one platform that vertically integrates all of the software infrastructure that is required for these new AI workloads?

That's right.

That's exactly right. DataStore is unstructured data. It's files, it's objects, very, very large, without a real understanding of what's in there. And then there's metadata. Every file, every object has metadata about the file itself. It has metadata that's contextual that comes with it. Let's say it's a genome. Who does this genome belong to? Which sequencer sequenced it, at what time? What are the characteristics of that person? And then you run that genome file through an inference function.

You understand more about it: which genes are in there, which mutations. All of that metadata was just sitting there, and people want it right next to the raw information on one hand, but they want the ability to query it on the other hand. And that led to this idea of a mashup between an unstructured data store and a structured database, enabling smart and insightful questions of the underlying raw information vicariously through this metadata layer.

That's how it started.

Yeah, everything in VAST is multi-protocol. And so, for example, you can write a file and then read an object. Everything is the same underneath the covers. And so the database is the same. You can write a Parquet object and then query it using SQL natively off of our platform, without needing any higher layers on top. And so now people are using it not just to analyze their metadata, but also as a data warehouse. And in the same way that we broke those fundamental trade-offs, it grows to extremely large scale without compromising on performance, without compromising on consistency and ACID requirements.

And so we find that in the database space, there are more trade-offs to be broken. Row-based databases and column-based databases, that all stems from storage. It stems from hard drives needing to be sequential. If we can give different views into the same information, then you don't need that complexity. You can consolidate, very similar to what we did in consolidating those tiers.

Yes, that's where we bring it to life. And so both the store and the database are static in nature. You write to them, you read from them, you query from them. Our customers didn't like that. They don't like the fact that their application is written in that way. In fact, they want it to be—I'm going to put a plug for you now—data-driven. They want everything to be based on the information as it flows in. That genome file came into the system, it should trigger that inference function that runs on it.

It should trigger an incremental training job that runs on it. That should run on a low-end GPU. This one should run on a high-end GPU. If we can build that language of triggers and functions where you can then understand more and more about your information and put that in the database, and that triggers more functions, and you have this recursive machine that's all data-driven, then we have the full stack, and that allows us to do things that couldn't be done before.

Okay. So the triggers are based on actions that happen. So you can have on new file, and then you can have a filter on that. It's not every file, but only files of type genome and only that belong to people above the age of 50. And then you call that function if that happens. Or as things get updated, you call another function. The functions themselves can be whatever you'd like. And of course, once we understand things about them, like the length or the urgency, then we can schedule them in a much more efficient manner.

The fourth piece of the platform, in addition to the data store, database, and data engine, is what we call the data space. And that allows us to go across geographies. And so now you can run a VAST instance in public cloud, AWS Region East, or in CoreWeave or on-prem or at the edge. And we stitch all of those instances together into one global namespace. And that allows us to schedule close to where the data is. It allows us to move functions rather than moving data across country lines.

In some cases, it's not allowed to move data out of Germany, but you can run a federated training job that's global. And so that again gives us an ability to do things that couldn't be done before. For example, break the speed of light. Data has gravity. Compute is a lot more lightweight.

Well, you don't need to move all of that. Not anymore. You don't need to move all of that information across oceans in order to bring it to one central location. Everything is distributed, and everything stays distributed in that sense.

Yes. So cloud, there's going to be the AWSs, the S3s of the world, possibly, which sit on top of bare metal, and we try and go as low as we possibly can to generate this advantage. But yes, continue.

That's correct.

Okay, so we try and find the most data-intensive organizations out there. We don't care how big the company is. We care about how much data they have. And if it's 100 terabytes, that's not interesting to us. If it's 100 petabytes, it's really interesting. And so that's where we gravitate towards. And those companies tend to have their data across multiple sites. Some of it is on-prem, some of it is in the cloud, some of it they're leveraging these new AI clouds.

And so wherever their data is, wherever it leads us, that's where we go. And we're agnostic to the underlying platform.

Yeah. So most of the data that we're talking about is natural information. It went through some type of analog-to-digital converter, whether it's a video camera or a genome sequencer or a microphone. And so we want to be as close to the origin of the data as we possibly can. Once you have a VAST instance at the edge, you can write wherever the data originated, and then you can analyze wherever you have compute resources to do so. And we take care of data movements and scheduling and all of that stuff.

We do. We try to build our own as much as possible in the data path. And so we've found that in order to leverage this architecture, we can't just bolt on a stack on top of us because it will dilute the value. And so everything is our own, or almost everything is our own. We don't use open source nearly as much as other companies do. And again, from the very low level of managing SSDs and running on CPUs and DPUs and GPUs all the way up to the protocol layers, we write ourselves.

Yes. So we never actually set out to be the next storage company. As you say, it was a way to be under the radar because VCs don't want to invest in that. Now that everybody understands what we're really about, then everybody wants to invest, but we don't need the money anymore. So that's an interesting conundrum.

And then you wouldn't have believed me. So, yeah, product management is interesting. You'll find we're 750 people. We have two product managers in the company. We lean on our customers to help us define the product. And we love to collaborate with our customers, to build with them and to build for them, and to innovate on their behalf. And so every good idea that we've had came from a customer or from a potential customer before we started selling.

And so once they started telling us, "It just works. We don't need you to add any more features to the storage layer," we started to ask them, "Well, what else do you need?" And they came up with, of course, their pain points and their challenges. And that's how we build. We always try to have at least 10% to 20% of R&D on advanced development, on future projects, have 10% to 20% of R&D interfacing with the field, fixing problems and adding small features that are required.

And then the bulk of the team is, of course, building the main feature set.

It's all been hard. I believe sales is the hardest thing because it's not in your control. You need somebody else to say, yes, I want this. I want to pay for this. And so I believe in shifting as many hard things as we can to R&D to build the best possible product that we can, and then making our sales team's lives a little bit easier. We don't look to the sides. We always look to optimal and how far from optimal can we be.

And that tends to have challenges. When we built our architecture, we didn't compromise. We wanted to break those fundamental trade-offs. That was difficult. It took us about a year, year and a half before we really started writing code in earnest because we went through those design phases. When we realized that we needed a new type of data reduction algorithm, a new type of data protection algorithm, those were not easy. And when I gave the team some pointers to, we need to do it that way, they very quickly came back and said, "You don't understand what you're talking about."

That won't work. And of course, they solved those hard problems rather than us shying away from the hard problems. But at the end of the day, that's why it's 10 times better, 100 times better. And that's why our customers keep buying more and more of it.

We open-source things on the periphery. If there's a plugin, if there's an interface, if there's a way to connect to other solutions, that piece we will open-source, but the core of the platform is proprietary.

Yeah, so we're just getting started on a lot of these things. The database just came out early last year. We're still in the early innings. The data engine is actually only coming out later this year. The data space is just at the very beginning of it. And so I think building out and filling out this vision over the next three to four years is what we're working on, and then we'll expand beyond. So in the same way that, in 2019, when we started selling, we exposed universal storage, and then it took us a few years to get to it.

Now we're doing the same with this data platform. Eventually, I think what is really required is an operating system. Every technological revolution that we've had, whether it's the personal computing revolution or the internet or mobile, it wasn't the hardware, it wasn't the chips that made it widespread. It was an operating system that made it easy for everybody to use. And I think today, in many cases, you still need a PhD in computer science to operate a large AI cluster. We want to make that easy for enterprises, easy for clouds, easy for everybody.

And that's the operating system that we're eventually trying to bring to market. That's our mission.

Yeah, I think it's stitching together a lot of different things across storage and compute and database and data movers across locations. But all of those things were built 10 and 15 and 20 years ago for a different problem set. And so even when you do stitch together all of those things, you end up, A, with the least common denominator between them, but B, with a solution that was good for numbers 10 years ago and not for GPUs, and definitely not for this age of generative AI that we're heading into.

Having a lot of data does not necessarily mean it's a big company. We just sold an exabyte to a company with less than 30 people. That's not common, but it exists in 2024, especially around AI. When we started, we went after early adopters. We went after hedge funds in the financial sector. Now we're selling into a lot of big banks. In the early days, we started with research centers and universities in the life sciences space and medical imaging.

Now we're selling into large pharmaceutical companies. And so we started with early adopters, with smart people that we could work with, and with people that did not have a lot of process and bureaucracy. We wanted direct access into the end users and, again, learn from them what they needed us to build. We started working with them a lot before we had a product, and by the time we had something to sell, it was theirs as much as it was ours. And so it was a very natural process of them moving from testing to using in production once it was generally available.

I guess hedge funds never really tell you, but they use it for improving their ability to analyze information. So, for example, backtesting. They would have quants that want to test their algorithms against historical trade data. And instead of doing it in batch overnight and needing to wait for results, it became interactive. Instead of doing it on two weeks' worth of data, they did it on 20 years' worth of data. So the quality of the results was better. Instead of having many different quant teams, each with their own infrastructure because they don't work with each other, they can now share without stepping on each other's toes.

That is structured data. And then what they realized with VAST is that they can start using satellite imagery, and they can start using news feeds and Twitter feeds, what's now called X, in order to understand more about where to trade. And that became an unfair advantage that they had versus everybody else.

We do. We are very close with our customers. And I would say the two things that we do well are R&D, building a product, and sales, selling the product. Everything else we're not very good at. We want a very intimate relationship, especially with the first several hundred customers, which is where we are today. And now, through partnerships, we're able to get reach into everybody else. And so, you mentioned HPE. HPE has tens of thousands of sellers out there, and they've decided to standardize on VAST as their file offering, and soon-to-be other parts of their stack.

And so they are giving us reach beyond those most data-intensive organizations. We're partnering with AI clouds to get reach into these smaller AI startups before they get to 100 petabytes. And again, the analogy of the operating system: we want to, on the one hand, make it easy for applications; on the other hand, have everyone underneath us help us sell.

NVIDIA, I would say, is our best and most natural partner wherever they sell compute and networking. We come in with storage and our data platform on top, and that becomes a full solution. They're also an investor in us. We're also leveraging their networking abilities, their DPUs. We're now running our containers in SmartNICs. We're leveraging their GPUs to accelerate our database abilities with RAPIDS. And so many, many different touchpoints, both in engineering and on the go-to-market side with NVIDIA.

I spend a lot of time on sales. I love to be in front of customers. That's where I learn the most. I don't spend a lot of time on HR. Hopefully everybody's happy at VAST. And, well, if you look at the people that were here seven years ago, they're still here. If you look at the people that were here six years ago, they're still here. We've built a culture that people like to work together. We have a group of extremely talented people on the one hand, but also very humble.

And they love to teach each other, to learn from each other, to solve hard problems together. And I think that's also key to being CEO. The only reason I have the CEO title is because I was the first one in, and they said somebody has to be CEO. That's definitely not something you would assign to me if you had a choice of other people. But the way I try to manage that is to hire really, really great people that know what they need to do a lot better than I do.

I just try and remove obstacles from their way and try to help them achieve those targets. And so they know how to do it. And they will tell me where they need help. I definitely don't know all of these things that a CEO needs to know.

So the big advantage that I had coming from EMC is that I saw how to build a business. Previous to EMC, I was with a lot of failed startups where we built really cool technology that nobody ended up using. And then I realized at EMC that building a business is so much more interesting because then you get to innovate over and over and over again, and you get this flywheel effect where you can, again, ride an exponential curve. The fact that we're worth $9 billion now, which is staggering, is because we keep tripling.

And if you start over, then you start from zero. That's not any fun. I had really good people that worked with me at EMC that were on the sales side, and they were able to help direct me in the right direction. And also, a lot of them joined VAST over the last few years.

I think it's all hard. If somebody knows of an easy way to do this, I'd like to get that email. And I was telling someone before, I have 4,000 unread emails. We don't have time to do all of the things that we need to do. As much as we try and as much as we work overnight and over the weekend, it's difficult. We're trying to do something that shouldn't be possible. The big companies that we're competing with have more resources than we do.

They have a better brand than we do. They have everything better than we do. And we, through a fighting spirit and through a weird culture that we've built—and it's an island of misfit toys, I call it—a lot of very, very interesting people that together are doing something that shouldn't be possible. That's what drives me to continue. I love the innovative aspect of it. I love the people that are working at VAST. I love our customers, but it's all very difficult.

So it's very reactive. I don't plan my days that much, which is the exact opposite of what they tell you to do. But I fight fires all day long. Wherever somebody has a burning need for me to help them, whether it's a need for me to help them close a deal, for me to help them find a way into a customer, or for me to help them solve a hard technical problem, I try to be available for that. And that means that, yes, I will miss a lot of emails.

I don't open Slack. I'm probably the only person in the company that doesn't use Slack. But if something is important enough, someone will text me or call me. And that's how I run my day. I tend to travel a lot. I spend three weeks out of the month in different places. I was last week in Pittsburgh and Chicago. Before that, London and Paris. Next week I'm in Dubai. The week after that, I'm doing Germany and Korea.

I like to be in the trenches with the sales teams so that I get a good intuition for what our customers are telling us, what they like about the product, what they don't like, where they'd like to see it go, and also to help train new people. Half the people at any given point in time have been here for less than a year. We need that direct touch in order to make sure everybody knows what they're doing, but more than that, to make sure that the culture is the one that we like and the one that we've worked so hard to build.

That's a really good question. And there are differences. For example, here people work from home mainly. In Israel, everybody's in the same office together. They won't have it any other way. In Israel, the culture is one of finding shortcuts and doing stuff very quickly, sometimes quick and dirty. You don't think about tomorrow as much because who knows where we're going to be tomorrow? When you're in the Middle East, here you build for 100 years. You see these buildings that were built 100 years ago and 150 years ago.

And it's a very—I think the art of building a company is knowing how much to draw from each of those extremes. And when do we need to build for the long term, and when are we just experimenting and we need to move fast and it's okay if things break along the way? I think that juxtaposition of cultures is the VAST culture. And it's very, very important to articulate it. In the early days, everyone's in the same room. You don't need to talk about these things.

They just happen as you grow. And as you grow at this pace, you have to explicitly tell people that you can leave a meeting in the middle and that you shouldn't waste time on internal crap, and that titles don't matter within the company, and that we don't have a hierarchy. We have a customer at the top and everybody else that's serving that customer. Those are things that people, especially coming from larger organizations, aren't used to, and they need to be taught.

Yeah, on building a sales team, I learned that salespeople come in all shapes, forms, sizes. Coming from Israel, I came with the preconceived notion that the sales team was quarterback with the rings, very charismatic, knows sports, knows how to entertain customers. There are those, and they do that very well. But then you have the introverts, and you have the people that are really good at relationships, and you have the people that are extremely good technically and are good at sales. And so, building a sales team, I would say, if you saw that movie Moneyball.

They don't all need to look in that same way, especially as you build a team. It's important that they complement each other and that they help each other. Many organizations have internal competition between salespeople, which is okay up to a point, but it's really important for them to feel like they're one team and they're helping each other. In doing sales, I found that the best way to sell is not to sell: to listen. I find that the more we let our customers talk to us, tell us about their environment, their pain points, their challenges, the more we can build for what they actually need rather than try to sell them what we've already built.

And I think the biggest, again, coming from Israel, the biggest reason that companies, startups fail is because you built something that looks really cool and you think it's awesome, but nobody really needs it. And so, when we started VAST, the first few months I was in front of potential customers asking a lot of questions. And the first ideas that we had, they shot down. They said, "We would never pay for that." And we had to go through many iterations until we came to a formula where they all said, "Yes, if you build that, we will buy it."

And then, of course, going back to the architects and developers, the reaction was, "Of course they'll buy that. That's impossible to build." But that goes back to: you want the hard stuff in the home court rather than when you're away, because it's more in our control.