 Time series data is any data that's stamped in time in some way. That could be every second, every minute, every five minutes, every hour, every nanosecond, whatever it might be. And typically, that data comes from sources in the physical world, like devices or sensors, temperature gauges, batteries, any device really, or things in the virtual world. Could be software, maybe it's software in the cloud or data in containers or microservices or virtual machines. So all of these items, whether in the physical or virtual world, they're generating a lot of time series data. Now time series data has been around for a long time and there are many examples in our everyday lives. All you got to do is punch up any stock ticker and look at its price over time in graphical form and that's a simple use case that anyone can relate to. And you can build timestamps into a traditional relational database. You just add a column to capture time. And as well, there are examples of log data being dumped into a data store that can be searched and captured and ingested and visualized. Now the problem with the latter example that I just gave you is that you got to hunt and peck and search and extract what you're looking for. And the problem with the former is that traditional general purpose databases, they're designed as sort of a Swiss army knife for any workload. And there are a lot of functions that get in the way and make them inefficient for time series analysis, especially at scale. Like when you think about IoT and edge scale where things are happening super fast, ingestion is coming from many different sources and analysis often needs to be done in real time or near real time. And that's where time series databases come in. They're purpose built and can much more efficiently support ingesting metrics at scale and then comparing data points over time. Time series databases can write and read at significantly higher speeds and deal with far more data than traditional database methods. And they're more cost effective. Instead of throwing processing power at the problem, for example, the underlying architecture and algorithms of time series databases can optimize queries and they can reclaim wasted storage space and reuse it. At scale, time series databases are simply a better fit for the job. Welcome to moving the world with influx DB made possible by influx data. My name is Dave Vellante and I'll be your host today. Influx data is the company behind influx DB, the open source time series database. Influx DB is designed specifically to handle time series data as I just explained. We have an exciting program for you today and we're going to showcase some really interesting use cases. First, we'll kick it off in our Palo Alto studios where my colleague, John Furrier will interview Evan Kaplan who's the CEO of influx data. After John and Evan set the table, John's going to sit down with Brian Gilmore. He's the director of IoT and emerging tech at influx data. And they're going to dig into where influx data is gaining traction and why adoption is occurring and why it's so robust. And they're going to have tons of examples and double click into the technology. And then we bring it back here to our East Coast studios where I get to talk to two practitioners doing amazing things in space with satellites and modern telescopes. These use cases will blow your mind. You don't want to miss it. So thanks for being here today. And with that, let's get started. Take it away, Palo Alto. Okay, today we welcome Evan Kaplan, CEO of influx data, the company behind influx DB. Welcome Evan. Thanks for coming on. Hey John, thanks for having me. Great segment here on the influx DB story. What is the story? Take us through the history, why time series, what's the story? So the history. History is actually pretty interesting. Paul Dix, my partner in this and our founder, super passionate about developers and developer experience. And he had worked on Wall Street building a number of time series kind of platform, trading platforms for trading stocks. And from his point of view, it was always what he would call a yak shave, which means you had to do a ton of work just to start doing work, which means you had to write a bunch of extrinsic routines. You had to write a bunch of application handling on existing relational databases in order to come up with something that was optimized for a trading platform or a time series platform. And he just developed this real clear point of view is this is not how developers should work. And so in 2013, he went through Y Combinator and he built something for, he made his first commit to open source influx DB at the end of 2013. And basically, from my point of view, he invented modern time series, which is you start with a purpose-built time series platform to do these kind of workloads and you get all the benefits of having something right out of the box so a developer can be totally productive right away. And how many people in the company, what's the history of these employees and stuff? Yeah, I think we're like, I always forget the number, but it's something like 230 or 240 people now. I joined the company in 2016 and I love Paul's vision. And I just had a strong conviction about the relationship between time series and IoT. Because if you think about it, what sensors do is they speak time series, pressure, temperature, volume, humidity, light, they're measuring, they're instrumenting something over time. And so I thought that would be super relevant over the long term. And I've not regretted it. Oh, no, it's interesting at that time to go back in history, the role of database is relational database, the one database to rule the world. And then as clouds started coming in, you're starting to see more databases, proliferate types of databases. And time series in particular is interesting because real time has become super valuable from an application standpoint. IoT, which speaks time series, means something. It's like time matters. Times, yeah. And sometimes data is not worth it after the time. Sometimes it's worth it. And then you get the data lake. So you have this whole new evolution. Is this the momentum? What's the momentum? I guess the question is, what's the momentum behind it? You mean what's causing us to grow? Yeah, the time series. Why is time series so important in momentum? What's the bottom line? Well, think about it. You think about it from a broad sort of frame, which is what everybody's trying to do is build increasingly intelligent systems, whether it's a self-driving car or a robotic system that does what you want to do or a self-healing software system. Everybody wants to build increasingly intelligent systems. And so in order to build these increasingly intelligent systems, you have to instrument the system well. And you have to instrument it over time better and better. And so you need a tool, a fundamental tool to drive that instrumentation. And that's become clear to everybody that that instrumentation is all based on time. And so what happened, what happened, what happened? What's gonna happen? And so you get to these applications like predictive maintenance or smarter systems. And increasingly you wanna do that stuff not just intelligently, but fast in real time. So millisecond response. So that when you're driving a self-driving car and the system realizes that you're about to do something, essentially you wanna be able to act in something that looks like real time. All systems wanna do that. They wanna be more intelligent and they wanna be more real time. And so we just happen to, we happen to show up at the right time in the evolution of a market. It's interesting, near real time isn't good enough when you need real time. Yeah, it's not. And it's like everybody wants, even when you don't need it ironically, you want it. It's like having the feature for, you buy a new television, you want that one feature. Even though you're not going to use it, you decide that you're buying criteria. Real time is a buying criteria. So Evan, what you're saying then is near real time is getting closer to real time as fast as possible. Right. Okay, so talk about the aspect of data because we're hearing a lot of conversations on theCUBE in particular around how people are implementing and actually getting better. So iterating on data. But you have to know when it happened to get, know how to fix it. So this is a big part of what we're seeing with people saying, hey, I want to make my machine learning algorithms better after the fact, I want to learn from the data. How does that, how do you see that evolving? Is that one of the use cases of sensors as people bring data in off the network, getting better with the data, knowing when it happened? Well, for sure, so for sure what you're saying is none of this is nonlinear. It's all incremental. And so if you take something, just as an easy example, if you take a self-driving car, what you're doing is you're instrumenting that car to understand where it can perform in the real world in real time. And if you do that, if you run the loop which is I instrumented, I watch what happens, oh, that's wrong. Oh, I have to correct for that. I correct for that in the software. If you do that four billion times, you get a self-driving car. But every system moves along that evolution. And so you get the dynamic of constantly instrumenting watching the system behave and do it. And this, and so self-driving cars, one thing, but even in the human genome, if you look at some of our customers, you know, people, you know, people doing solar arrays, people doing power walls, like all of these systems are getting smarter. Well, let's get into that. What are the top applications? What are you seeing with Influx DB, the time series? What's the sweet spot for the application use case and some customers? Give some examples. Yeah, so it's pretty easy to understand on one side of the equation. That's the physical side is, sensors are getting cheap, obviously, we know that. And they're getting, the whole physical world is getting instrumented. Your home, your car, the factory floor, your wristwatch, your healthcare, you name it, it's getting instrumented in the physical world. We're watching the physical world in real time. And so there are three or four sweet spots for us, but they're all on that side, they're all about IoT. So they're thinking about consumer IoT, kind of projects like Google's Nest, Tato, particle sensors, even delivery engines like Wrappy, we deliver the Instacart of South America, like anywhere there's a physical location doing, that's on the consumer side. And then another exciting space is the industrial side, factories are changing dramatically over time, increasingly moving away from proprietary equipment to develop or driven systems that run operational, because what has to get smarter when you're building a factory is systems all have to get smarter. And then lastly, a lot in the renewables and sustainability. So a lot, you know, Tesla, Lucid Motors, Nikola Motors, you know, lots to do with electric cars, solar arrays, windmills arrays, just anything that's going to get instrumented that where that instrumentation becomes part of what the purpose is. It's interesting the convergence of physical and digital is happening with the data. IoT you mentioned, you know, you think of IoT, look at the use cases there, it was proprietary OT systems now becoming more IP enabled internet protocol and now edge compute, getting smaller, faster, cheaper, AI going to the edge, now you have all kinds of new capabilities that bring that real time and time series opportunity. Are you seeing IoT going to a new level? What's the IoT, where's the IoT dots connecting to? Because, you know, as these two cultures merge, operations basically, industrial, factory, car, they got to get smarter. Intelligent edge is a buzzword, but I mean, it has to be more intelligent. Where's the action in all this? So the action really, really at the core, it's at the developer, right? Because you're looking at these things, it's very hard to get an off the shelf system to do the kinds of physical and software interactions. So the actions really happen at the developers. And so what you're seeing is a movement in the world that maybe you and I grew up in with IT or OT, moving increasingly that developer-driven capability. And so all of these IoT systems, they're bespoke. They don't come out of the box. And so the developer, the architect, the CTO, they define what's my business? What am I trying to do? Am I trying to sequence a human genome and figure out when these genes express themselves? Or am I trying to figure out when the next heart rate monitor is gonna show up on my Apple Watch? Right, what am I trying to do? What's the system I need to build? And so starting with the developers where all of the good stuff happens here, which is different than it used to be, right? Used to be you'd buy an application or a service or a SaaS thing for, but with this dynamic, with this integration of systems, it's all about bespoke. It's all about building something. So let's get to the developer real quick. Real highlight point here is the data. I mean, I can see a developer saying, okay, I need to have an application for the edge, IoT edge or car. I mean, we're gonna have, I mean, Tesla got applications of the cars right there. I mean, there's the modern application life cycle now. So take us through how does this impacts the developer? Does it impact their CICD pipeline as a cloud native? I mean, where does this all, where does this go to? Well, so first of all, you're talking about there was an internal journey that we had to go through as a company, which I think is fascinating for anybody who's interested, is we went from primarily a monolithic software that was open source to building a cloud native platform, which means we had to move from an agile development environment to a CICD environment. So to the degree that you're moving your service, whether it's Tesla monitoring your car and updating your power walls, right? Or whether it's a solar company updating the arrays, right? To the degree that that service is cloud, then increasingly we move from an agile development to a CICD environment, which you're shipping code to production every day. And so it's not just the developers, all the infrastructure to support the developers, to run that service and that sort of stuff. I think that's also going to happen in a big way. When your customer base that you have known and you see evolving with inflectDB, is it that they're going to be writing more of the application or relying more on others? I mean, obviously there's an open source component here. So when you bring in kind of old way, new way, old way was I got a proprietary app platform running all this IoT stuff and I got to write, here's an application that's general purpose. I have some flexibility, somewhat brittle, maybe not a lot of robustness to it, but it does its job. A good way to think about this is- Versus new ways is what? So yeah, good way to think about this is what's the role of the developer slash architect, CTO, that chain within a large enterprise or a company. And so the way to think about it is I started my career in the aerospace industry. And so when you look at what Boeing does to assemble a plane, they build very, very few of the parts. Instead what they do is they assemble, they buy the wings, they buy the engines, they assemble, actually they don't buy the wings. It's the one thing, they buy the material for the wings. They build the wings because there's a lot of tech in the wings and they end up being assemblers, smart assemblers of what ends up being a flying airplane, which is pretty big deal even now. And so what happens with software people is they have the ability to pull from, you know, the best of the open source world. So they would pull a time series capability from us and they would assemble that with potentially some ETL logic from somebody else. So they'd assemble it with a Kafka interface to be able to stream the data in. And so they become very good integrators and assemblers, but they become masters of that bespoke application. And I think that's where it goes because you're not writing native code for everything. So they're more flexible. They have faster time to market because they're assembling. Way faster. And they get to still maintain their core competency, aka the wings in this case. They become increasingly not just coders, but designers and developers. They become broadly builders is what we like to think of it. People who start and build stuff. By the way, this is not different than the people just up the road Google have been doing for years or the tier one Amazon building all their own. Well, I think one of the things that's interesting is that this idea of a systems developing, a system architecture. I mean systems have consequences when you make changes. So when you have now cloud data center on premise and Edge working together, how does that work across the system? You can't have a wing that doesn't work with the other wing kind of thing. That's exactly. But that's where that Boeing or that airplane building analogy comes in. For us, we've really been thoughtful about that because IoT, it's critical. So our open source Edge has the same API as our cloud native stuff. It has enterprise on-prem Edge. So our multiple products have the same API and they have a relationship with each other. They can talk with each other. So the builder builds it once. And so this is where when you start thinking about the components that people have to use to build these services is that you want to make sure, at least that base layer, that database layer that those components talk to each other. Well, I have to ask you, if I'm the customer, I'll put my customer hat on. Okay. Hey, I'm dealing with a lot. Does that mean you have a PO for me? A big check. I'm blank check. If you can answer this question. Only if the tech. If you get the question right. I've got all this important operations stuff. I've got my factory. I've got my self-driving cars. This isn't like trivial stuff. This is my business. How should I be thinking about time series? Because now I have to make these architectural decisions, as you mentioned, and it's going to impact my application development. So huge decision point for your customers. What should I care about the most? What's in it for me? Why is time series important? Yeah, that's a great question. So chances are, if you've got a business that was 20 years old or 25 years old, you were already thinking about time series. You probably didn't call it that. You built something on Oracle, or you built something on IBM's DB2, right? And you made it work within your system, right? And so that's what you started building. So it's already out there. There are probably hundreds of millions of time series applications out there today. But as you start to think about this increasing need for real time and you start to think about increasing intelligence, you think about optimizing those systems over time. I hate the word, but digital transformation. Then you start with time series. It's a foundational base layer for any system that you're going to build. There's no system I can think of where time series shouldn't be the foundational base layer. If you just want to store your data and just leave it there and then maybe look it up every five years, that's fine. That's not time series. Time series is when you're building a smarter, more intelligent, more real time system. And the developers now know that. And so the more they play a role in building these systems, the more obvious it becomes. And since I have a PO for you in a big check, what's the value to me when I implement this? What's the end state? What's it look like when it's up and running? What's the value proposition for me? So when it's up and running, you're able to handle the queries, the writing of the data, the down sampling of the data, transforming it in near real time. So the other dependencies that a system gets for adjusting a solar array or trading energy off of a power wall or some sort of human genome, those systems work better. So time series is foundational. It's not like it's doing every action that's above, but it's foundational to build a really compelling intelligent system. I think that's what developers and architects are seeing now. Bottom line, final word, what's in it for the customer? What's your statement to the customer? What would you say to someone? Looking to do something in time series on edge. Yeah, so it's pretty clear to us that if you're building, if you view yourself as being in the business of building systems, that you want them to be increasingly intelligent, self-healing, autonomous. You want them to operate in real time that you start from time series. But I also want to say what's in it for us, influx. What's in it for us is people are doing some amazing stuff. You know, I highlighted some of the energy stuff, some of the human genome, some of the healthcare. It's hard not to be proud or feel like, wow, somehow I've been lucky. I've arrived at the right time in the right place with the right people to be able to deliver on that. That's also exciting on our side of the equation. It's critical infrastructure, critical operations. Yeah, yeah. Great stuff. Evan, thanks for coming on, appreciate this segment. All right, in a moment, Brian Gilmore, director of IoT and emerging technology that influx state will join me. You're watching theCUBE, leader in tech coverage. Thanks for watching.