 From San Mateo, it's theCUBE, covering Scalar Innovation Day, brought to you by Scalar. Everyone, welcome to this special on the ground, Innovation Day. I'm John Furrier, host of theCUBE. We're here at Scalar's headquarters in San Mateo, California, the heart of Silicon Valley. We're here with the co-founder and CTS, Steven Sirwinsky and Jeff Lowe, Product Marketing Director. Thanks for having us. Thanks for having us. Thank you. Been a great day so far. Talked to the other co-founders and team here. Great product opportunity. You guys been around for a couple of years. Got a lot of customers. Just newly minted, funded Series A and standard startup term that seems early, but you guys are far along. You guys are unique architecture. What's so unique about the architecture? Well, thanks. There's really three elements of the architecture's design that I would highlight that differentiates us from our competitors. Three things that really set us apart. I think the biggest, the first one is our use of a commonar database. This is what allows us to provide a really superior search experience, even though we're not using keyword indexing. It's purpose built for this problem domain and just provides us with great performance and scale. The second thing I would highlight would be the use of, well essentially we're a cloud native solution. We have been architected in such a way that we can leverage the great advantage of cloud. The scalability that cloud gives you, the elasticity that cloud gives you. And our architecture was built from the grounds up to leverage that. And finally, I would point out the way that we do our data, the way that we don't silo data by data type. Essentially any type of observability data, whether it's logs or tracing or metrics, all that data comes into this great platform that we've written that provides a really great superior query performance over. Yeah, we talked earlier about discoverability, but I want to just quickly ask you about the keyword indexing in the cloud native. To me, that seems to be two big pieces because a lot of the older, well current standards, people who were stated there a few years ago, 10 years ago, keyword indexing was a big part of it. And cloud native was just still emerging except for those folks that were born in the cloud. So this is a dynamic. How important is that? It's just critical. I mean, here, why don't we go to the whiteboard? I'd love to kind of talk about this in a little more detail. In particular, so let's talk about keyword indexing. Because you're right, this is a lot of the technology that people leverage right now, it's what all of our competitors do. In keyword indexing, let's look at this from the point of view of a log ingestion pipeline. So in your first stage, you have your input. You've got your raw logs coming in. The first thing you do after that typically is parse. You're gonna parse out whatever fields you want from your logs. Now all of our competitors, after they do that, they do an indexing step. This has a lot of expense to it. In fact, I'm gonna dig into that. After the log content is indexed, it's finally available for search where it'll be returned as a search result. This one little box, this little index box, actually has a lot of costs associated with it. It contributes to the bloat of storage. It contributes to the cost of the overall product. In fact, that's why a lot of our competitors charge you based on how much you're indexing, not even how much you're ingesting. When you look at the cost for indexing, I think you can break it down into a few different categories. First of all, building the index. There are certain costs with just taking this data, building the index and storing it. Computational storage, memory, everything. But you build the index in order to get superior query performance, right? So that kind of tells you that you're gonna have another cost. You're gonna have an optimization cost where the indexes that you're building are dependent on the queries that your users want to conduct, right? Because you're trying to make sure you get as good of query performance as possible. So you have to take a look at the queries that your users are performing, the types of logs that you're coming in, and you have to decide what indexing that you want to do, okay? And that cost is shouldered by the burden of the customers. Okay, but nothing static in this world. So at some point, your logs are gonna change. The type of logs you're ingesting is gonna change. Maybe your query is gonna change. And so you have another category of costs, which is maintenance, right? You're gonna have to react to changes in your infrastructure. It's use the type of logs you're ingesting. And basically, this just creates a whole big loop where you have to keep an eye on your performance. You have to be constantly optimizing, maintaining, and just going around in the circle, right? And for us, we just thought that was ridiculous because all this cost is being borne by the customer. And so when we designed the system, we just wanted to get rid of that. That's the classic shark fin. You see a fin underneath is great why it's gonna eat you up, or iceberg. You see that tip? You don't see what's underneath. This seems to be the key problem because the trend is more data, new data, microservices is gonna throw off new data types. So the data types is going up as well. Does that consistent with what you guys just seen? That's consistent. I mean, what we hear from our customers is they want flexibility, right? These are customers that are building service-oriented, highly scalable applications on top of new infrastructure. They're reacting to changes everywhere. So they want to be able to not have to optimize their queries. They're not gonna wanna maintain things. They just wanna search product that works, that works over everything that they're ingesting. So good plan, you eliminate that flywheel of cost for the index, but you guys do a proprietary columnist or that's the key on your end. That's the key on that. That gives you flexibility on data types. Yes, it does. And here, let me draw a little something to kind of highlight that. Because of course it begs the question, okay, we're not doing keyword indexing, what do you do? What we do actually is leverage decades of research and distribute systems on commoner databases. And I'll use an example in order to kind of- And people know in the database world that's super fast. Yeah. It's like a Ferrari, basically. Yes, it's a Ferrari. Because you're able to do much more targeted, essentially analysis on the data that you wanna be searching over, right? And one way to look at this is, no, let's take a look at a web access log, okay? And when we think about this in tables, we think that each line in the table represents a particular entry from the access log, right? And your columns represent what fields you've extracted. So for example, one of the fields you might extract is the HP status code. Was it a success or not, right? Or you might have the URI, or you might have the user agent of the incoming web request, okay? Now, if you're not using a commoner database approach to execute a query where you're trying to count the number of non-200s that your web server has responded with, you'd have to load in all the data for this table, right? And that's just, it's overkill. In a commoner database, essentially what you do is you organize your data such that each column essentially is saved as a separate file. So if I'm doing a search where I just want to count the number of non-200s, I just have to read in these bytes. And when your main bottleneck is sloshing bytes in and out of main RAM, this just gives you orders of magnitude better performance. And we've just built this optimized engine that does essentially this at its core and does it really well, really fast, leveraging commoner database technology. So it lowers the overhead. Yes. You have to load the whole table in. That's going to take time. Queering the table is going to take time. That seems to be the update. That's exactly right. Awesome, right? Okay, cool. All right, Jeff. So, you're the director of product marketing. So you got a genius pool of co-founders here, Scaler, been there, done that, but all have successful track records as tech entrepreneurs, not their first rodeo. Making it all work, getting it packaged for customers is the challenge that you guys have. You've been successful at it. What does it all mean? Yeah, it essentially means helping them explore and discover their data a lot more effectively than they have been before. With applications and infrastructure becoming much more complex, much more distributed, our engineering customers are finding it increasingly difficult to find answers. And so all of this technology that we've built is specifically designed to help them do that at much greater speed, much greater ease, much more affordably and at scale. We always like to say we're fast, easy, affordable at scale. Yeah, I noticed in getting to know you guys and interviewing people around the company, the tagline, built by engineers, for engineers, is interesting, one, you guys are all super nerdy and geeky so you get the tech and you take pride in the tech and the code, but also your buyers are also engineers because they're dealing with cloud-native, whole-nother DevOps level of scale, where they love scale. People in that market love infrastructure as code. This is kind of the ethos of that market. But speed scale is what they live for and that's their competitive advantage in most cases. How do you hit that point there? What's the alignment with the customers on scale and speed? Yeah, with the couple of things that Steven had mentioned, the columnar database, and he mentioned cloud-native, we like to refer to that as massively parallel or true multi-tenancy in the cloud. Those two things give us really two key advantages when it comes to speed. So speed on ingest, that goes back to what Steven was talking about. With the columnar database, we're not having to wait to build the index so we can ingest orders of magnitude faster than traditional solutions. So whereas a conventional solution might take minutes, even up to hours to ingest large sets of data, we can literally do it in seconds and so the data's available immediately for use and for search. One of our customers, in fact, the one that I'm thinking of down in Australia, actually uses our live tail because it actually works and as they push code out to production, they can actually monitor what happens and see if the changes are impacting anything positively or negatively. And speed to truth is a tagline. The marketing people came up with, which is cool. I love that. Kind of our philosophy, get the content out there and let the people decide. But in your business, ingestion's critical. Getting the ingestion to value timeframe nailed down is table stakes. People, engineers want to test stuff and it doesn't work out of the box when they ingest it and they don't see value. They're not going to kind of go to the next level. It's kind of a psychology of the customer. Yeah, you know, when you're pushing code on an hourly basis, sometimes even minutes now, the last thing you want to do is wait for your data to analyze it. Especially when a problem occurs. When a problem occurs and it's impacting a customer or impacting your overall business, you immediately go into firefighting mode and you just can't wait to have that data become available. So that speed to ingest becomes critical. You just don't want to wait. The other aspect on the speed topic is speed to search. So we talked about the types of searches that our columnar database affords us. Couple that with a massively parallel and true multi-tenancy approach. Basically means that you can do very, very ad hoc searches extremely quickly. You don't have to build a keyword index. You don't actually have to even build a query or learn how to build queries and then run it and then wait for it and maybe in the meantime wait to get a coffee or something like that. I mean we grew up in Google search, everyone who used the web knows what search is and discovery is kind of the industry word in discovery and navigation. But one of the things about searches that made Google say great was relevance. You guys seem to have that same ethos around data, discoverability, speed and relevance. Talk about the relevance piece because I think that to me is what is everyone's trying to figure out as more data comes in, you mentioned some of the advantages Steven around complexity around data types. More data types are coming on so relevancy is what everyone's chasing. Yeah, so one of the things that I think we are very good at is helping people discover what is relevant. There are solutions out there, in fact there's a lot of solutions out there that will focus on summarizing data, letting you easily monitor with a set of metrics or even trace a single transaction from point A to point B through a set of services. Those are great for telling you that there is a problem or that a problem exists maybe in this one server, so this one server. But where we really shine is understanding why something has happened, why a problem has occurred. And the ability to explore and discover through your data is what helps us get to that relevancy. I remember meeting Larry and Sergey back in 1998 and from day one it's, find what you're looking for. And they did their thing. So I want to just quickly have you guys explain because I think one thing that also has come up and I'd love to get your take on it guys is multi-tenancy. You're in the clouds, you get a lot of scale, a lot of resource. Talk about the, why multi-tenancy is an important piece and what does that specifically mean for the customer vis-a-vis potentially competitive solutions and what do you guys bring to the table? So that seems to be an important discussion point. Sure, no and it is one of the key pieces of our architecture. I mean when we talk about being designed for the cloud this is a central part of that, right? When you look at our competitors, for the most part a lot of them have taken existing open source off the shelf technologies and kind of taken that and shoved it into this square hole of let's run it in the cloud, right? And so they're building these SaaS services where essentially they pretend like everyone's got access to a lot of resources but under the covers they're sitting there spinning up these open source solutions instances for each of the customers. Each of these instances are only provisioned with enough RAM, CPU for that customer's needs, right? And so heaven forbid you try to issue more queries than you normally do or try to use more storage than you normally do because your instance will just be capped out, right? And also it's kind of inefficient in that when your users aren't issuing queries those CPU and RAM resources are just sitting there idle. Instead what we've done is we've built a system where we essentially have a big pool of resources. We have a big pool of CPU, a big pool of RAM, a big pool of disk. Everyone comes in, gets access to that. So it doesn't matter what customer you are, your queries get full access to all these CPUs that we have running around, right? And that's the core of multi-tenancy is that we're able to not provision for just one little, for each individual customer, but we have a big pool of resources that everyone gets to look at. And that's going to hit the availability question on and it's also going to have a side effect for all those app developers who want to build AI and stuff, use data and build these microservices systems. They're going to get the benefit because you have that closed loop or flywheel if you will. Yeah. Yeah, the, if I could just add the multi-tenancy really gives us a lot of economies of scale, both from the over-provisioning and the ability to really effectively use resources. But we also have the ability to pass those savings on to our customers. So there's that affordability piece that I think is extremely important to find the answers. This architecture affords that. Steven, I want to ask you, because I know the DevOps work pretty well and people are, they're hardcore, you know. They build their own stuff. They don't want us to have a vendor. Well, I can do this myself. This always comes up there, but these use cases here, you guys seem to be doing well in that environment. Again, engineering led solution, which I think gives you guys a great advantage. But what's the, how do you handle the objection when you hear someone say, well, I could do it. Well, I'm just going to do it myself. What I always like to point at is, yes, you can up to a degree, right? We often hear people that use open source technologies like Elk, they can get that running and they can run it up to a certain scale. Like, you know, tens of gigabytes per day of logs, they're fine, right? But with those technologies, once it goes above a certain scale, it just becomes a lot more difficult to run. It's one of those classic things. You know, getting 50% of the way there is easy. Getting 80% of the way there is a lot harder. Getting 100% is almost impossible, right? And you as whatever company that you're doing, whatever product you're building, do you really want to be spending your engineering resources pushing through that curve, getting to 80%, 100% of kind of a good, a great solution? No. What we always pitch is like, look, we've already solved these problems, these hard problems for this problem domain. Come and leverage our technology. You don't have to spend your engineering capital on that. And then the people who are doing that scale that you guys provide, they want, they need those engineering resources somewhere else. So I have to ask you just basically the follow up question, which is, how does the customer know whether they have a non-scalable or scalable solution? Because some of these SaaS services are masquerading as scalable solutions. No, they are. I mean, we actually encourage our customers when they're in the pre-sale stage to benchmark against us. We have a customer right now that's sending us terabytes of data per day as a trial, just to show that we can meet the scale that they need. We encourage those same customers to go off and ask the other competitors to do that. And the proof is in the pudding. And it's looking, how's the results looking good? Yeah. So bring on the ingest. Yes. That's the sales bitch. Yes. Guys, thanks so much for sharing the insights. Even appreciate it. Jeff, thanks for sharing. Appreciate it. Thank you. I'm John Furrier with theCUBE here for a special innovation day at Scalers headquarters in the heart of Silicon Valley, San Mateo, California. Thanks for watching.