The Exchanges

Q So we alluded to, uh, Influx three dot O, which, uh, effectively you all just announced, uh, congratulations. So it's from the outside. It looks like a major effort at rewriting a bunch of things. Why did you do that in the first place, and, uh, what is it that you did?

A We started writing, depending on how you look at it, we started writing in FluxDB, I don't remember when the first repository opened, let's call it three, three and a half years ago, so it's been a really big project. And there were certain assumptions after being in the market for, you know, at that point for seven years and, you know, probably at that point having 12, 1300 customers, we just learned a lot about what customers were doing and what issues they were having. And so we set out to solve, let's call it four or five problems. So the first problem we set out to solve is, is, um, is the issue of cardinality. So when you get a database that's describing a rich set of data around a time series This thing, you can run into cardinality problems that can choke off, um, can choke off the performance of the data.

AI assessment note: “we just learned a lot about what customers were doing and what issues they were having.”

Q all so fast that it might be tomorrow morning. In terms of, um, more pedestrian use cases of machine learning, I mean, it sort of feels like if you're in an IoT world, there should be a bunch of use cases where, okay, well, if temperature goes up by a certain whatever, recognize that pattern, machine learning model. And then do something. Do you have a bunch of that already?

A Yeah, that's, that's what most people do with our stuff, but I would call those pretty simple control loops. Um, you know, pretty, um, a good example that is the Tesla Powerwalls. I think there are roughly a million of them out there now. They all, they all spew into influx into the database and they can trade energy in a 4:02 interval based on that data that's coming off. And so, In my house, I have a bunch, I have three Tesla Powerwalls, and so, um, I can sell my energy back to the grid based on that. It's all based on influx, and the app runs, and that. But that's the kind of stuff that people are increasingly doing, because any, you know, the fundamental, our fundamental belief is that any human design systems wants to become increasingly autonomous. Doesn't mean it has to be, doesn't mean it will be, but it wants to be. Anything that you can do, It wants to be increasingly autonomous with less human intervention. It's a long journey.

AI assessment note: “Yeah, that's, that's what most people do with our stuff”

Q Yeah. And so I guess you sort of just alluded to it, but like, why do you need a separate database for that kind of data? Why can't a general purpose database Do this.

A There's always just two kinds of people in the world. Those who believe there are two kinds of people in the world and those who don't. So yes, in some cases there are, for many use cases, you can use a general purpose database. People have built stuff on Postgres. People have built time series on Mongo. Like those are highly useful. But if you're ingesting huge amounts of data, you want the query response time. You want really zero time to be read. You want low latency data. You want a truly operational platform. You get to a level where Where the thing that you use to monitor your swimming pool or your home thermostat isn't the same thing that you'd monitor, you know, 50,000 power walls in a locality.

AI assessment note: “if you're ingesting huge amounts of data, you want the query response time”

Q Fantastic. Maybe, so the, the one-on-one on what time series?

A So, so think about it is, is, you know, the easiest way to think about it is sensor analytics, but, but anything that's measuring time, anything you want to measure, any telemetry that you're capturing over time that you want to describe time, time, what happened, what happened, what happened, what happened. So at a very broad, a broad case, anything that's really observable that you want to observe over time. It turns out that most data sets are really easily understood in the concept of time or most usefully understood in the concept of time. And so if you build something optimized for time series, um, it can be really useful, particularly as it relates to the physical world.

AI assessment note: “easiest way to think about it is sensor analytics, but, but anything that's measuring time”

Q big news is Influx III. So we're going to talk about all of that in detail, uh, but, uh, first thing is first. Uh, what is Influx and maybe what is time series? We're getting an effort, um, as in prior conversations to make this broadly, uh, interesting to, uh, to, to folks that may not follow the very, uh, you know, every single detail of this, of the space.

A So first of all, I should make Paul stand up and take a bow. So if you have any questions, Paul is the original author of Influx TV. Um, he's a native New Yorker, and I love telling this story because he can't stop me from telling it in my own way. Um, and, um, I met Paul in 2015. I was working at a venture firm, um, helping out with other CEOs. Um, Paul and I connected, um, on something totally unrelated to technology is we were both CrossFitters. And so you, those of you know, the joke is if you've ever met a CrossFitter, they tell you that in the first First, 30 seconds, so we bonded around, around that, and over time, I met him just after he spoke here, um, and over time, he asked me if we would work together, and, and I said yes, and so we've been married now for almost 10 years, um, and, um, and we could do a whole speech on what it means to have a technology partner and a CEO coming together and, um, on that, but anyway, Influx started in, in, Um, and Paul had, as, as many companies, they had originally started to build, um, basically a data dog, kind of server monitoring, kind of SaaS service, and then had to build a database to service that, then realized in a pivot that the database actually was more important than actually the SaaS service that they could build, and built, um, Influx, which was, um, It was built in Go, and it was built specifically for the time serie…

AI assessment note: “built, um, Influx, which was, um, It was built in Go”

Q Do you want to define what cardinality or high cardinality is for us?

A So think about a measurement, and think about all the metadata around the measurement, and think about ephemeral measurements like network, networks, you know, source and destination. You get these, you know, millions and billions of combinations that are really unique to time series, and so when you start getting those, they can really choke off a database. And kill performance. So what we found is that the upper bounds of our, our series one and series two databases, um, you know, performance would slow down and customers would have to cut out some of the measurements and they would have to pull back on, on the richness of their data, which is not what you really want. And so we had to solve the cardinality problem. And so that required a different look at the architecture. Two is, um, we, we had to solve the storage problem. So what was happening is our compute and our, and our storage were linked, and so customers wanted to keep their data around a long time. It could be really expensive, and so if you were keeping, we have some customers, sort of utilities, things like that, that had to keep data for 10 years, and so all of a sudden, compute and storage becomes a really expensive burden, and so we wanted to have an object storage-based system, which was non-trivial. To build a real-time object-based storage is non-trivial and, um, And, and so we, we embarked on that. The t…

AI assessment note: “You get these, you know, millions and billions of combinations”