In The Arena by TechArena - Expanso's David Aronchick on Data Gravity and Pipeline Debt

Episode Date: July 2, 2026

In this episode of In the Arena, David Aronchick, CEO of Expanso, breaks down the architectural philosophy behind Expanso, why data gravity changes everything Kubernetes got right about distributed compute, and what it actually looks like when teams treat raw data like a toxic waste dump (the good kind of discipline).

Welcome to Tech Arena, featuring authentic discussions between tech's leading innovators and our host, Alison Klein. Now, let's step into the arena. Welcome in the arena. My name's Allison Klein. Today, I am really excited to be joined by David Arun Chick, CEO of Expanso. Welcome to the program, David. Thank you so much. Wonderful to be here. So, David, this is the first time you're on the show. So why don't we just do a... brief background on your history in the tech sector and how you became the founder and CEO of Expans.

Shetank, first of many, I hope. You know, I've been doing tech for a long time. That's at these gray hairs, my beard mean. I started at Microsoft. I have worked at Microsoft, Amazon, Google, Microsoft again. I had now startup. And I've been a startup founder. This is now my fourth startups that I have found.

So I've definitely gone around the bend. As far as the CEO of Expanso, what I found is that I was very lucky to be part of the early group at Kubernetes, which was an open source distributed compute system, which really, you know, kicked off a lot of revolution in the mid-2010s. And not just them, they were built on the history of many other folks, but it really didn't change the way that people thought about things. Previously, most folks thought about a single big machine, and then I'm going to deploy my jobs and get that running. Kubernetes among others were one that really said, hey, you know what, actually it might be a little easier to spread your jobs all over these various machines over an entire cluster. And the reason I bring this up is I realized at the time that the compute was part of it, but we kept hearing from customers that the data was a part of it as well. How do you think about data in the same structured way where you're like, hey, you know what?

It's nice to have all your data in a single place, but it'd be really nice if you could figure out a way to treat, all this data that was spread over these various machines in the same way, where you can just say, hey, you know what, I need this data. I need you to go collect this or run it or whatever. And the difference between computer data is that it turns out it's not just inside a single cluster or cloud. It may be across many clouds. It may be on-prem and maybe all these various things.

And I kept waiting for the industry to come around and get that going. Never ended up happening. So in 2022, I founded the Open Dars project, which ended up becoming expansive in Honeystreet. and I've been CEO or since. Now, I was thinking back to Kubernetes, and obviously this has been foundational to cloud computing in the way the cloud architectures are built and managed. You know, when you think about the scale

that comes out in that background, how do you see abstraction and scale working for data? And what did you learn from Kubernetes to actually lay the foundation for that? Yeah, that's a terrific question. The first and most fundamental thing, I think the second half of your first, problem first is the idea of being declarative. Again, for those that aren't deep in the space, one thing that with Kubernetes was really revolutionary about was that everything in the system was

declaring and it allowed you to push a jaw and say, hey, when the stuff gets to this final, you're done. But until it gets there, I want you to take care of it and do the rest of it, right? Before that, most stuff was much more imperative, meaning you would wait, you would tell the system, hey, check, go do this, oh, now I need to check again, now I need to rerun this. I need to figure out what changed, what didn't change, all the kind of stuff. And that was really a big deal at the time to have a system take over, to have a system, have an expectation of the final state, and that it do all the work to make sure I got there. Now, that required a lot of architecture in order to make that happen.

But that was really powerful and it stuck with me for a long time. In the data space, what you see is a lot of the same kind of thing that I keep waiting for the world to adopt, which is, hey, you know what, I need that data over there. I need this job to run over there. I need this to be like aware of the data over there. And then I want you to move that into my backend data warehouse and work with it once it gets there. Today, we do all the work, right?

We run these ETL jobs. We run checking. We do pulling. We do all this kind of repeatable work to say, hey, you know what? I'll take care of the hard work in order to make sure that data actually in there and get there in the right schema and the right structure. And it was the right size and shape in order for me to move it. And that was something that I was like, hey, you know what? In our system, we could build it so that we could help you do that.

We could help reliably get this data pipelines up. We can help you reliably ensure that if the pipeline broke, it re-raned it or did this or that and the other thing. And that's very much what we have built as well. And in particular in the data world, this is incredibly important because, while Kubernetes is amazing, it really is built for a single zone and a single cloud owner, meaning all that compute that I was talking about, it expects to be able to talk back and forth to the API server on a very regular. basis. If you start to lose connectivity for any reason, you're going to have a bad time. Again, this is tweakable, but it's just, it's not how things like to work. With data, you don't get

that option, right? You don't get to reschedule all the data job. Get to move it to a different cloud because it's not working because the data's over there. You've got to respect that the data's there. It's got gravity. And so you need it to work in that location, even if there's disconnection. And again, that's part of our core philosophy that when things disconnect, it keeps running. When it reconnects, we resolve it, make sure that things work properly and that nothing changed over there, that it changed over here, that the data is stored and forward, et cetera, et cetera. So that was a real architectural shift, but we couldn't have made that shift without the knowledge

that we have taken away from Kubernetes. That makes a lot of sense. And, you know, one of the things that really struck me in our previous conversation was this concept of data in a particular location and isolation is neither good or bad, but without context, it's hard to know what it actually means. And I think that this kind of felt like the foundation of what you're doing with Expanso, like, how do you look at that from a central lens in this distributed landscape to figure out how to put context around that data? Yeah. And what I will say, the real insight in our previous conversation and even now

that you provided was that context is so important in the world of AI today, right? AI for most purposes is stateless. You say, hey, you know what, make this calendar entry for me, right? You may have yesterday talked to a calendar 17 times, but all you said in this little word was, like, make this calendar entry for me, which calendar, what time's on are you in, yada, yada, yeah, right? There's all this kind of stuff involved. And that's all context. Right now, we give AI's very little context, generally speaking. What does that mean? That means you have it up in hand, ideally seamlessly, so you don't have to think about it,

all the context involved. So it knows that I have now flown to London and what I say make this meeting for me, don't take the Pacific time that I'm normally on, make it on London time. And so that's what part of it is. Now, this is obviously an individual thing. The example I give all the time is, let's say I had a cash register, a series of cash register sitting in a store. And for last hours, cash register number of three set no data through. Okay, well, what, right? What possible reason could it be? Could it be the store is closed?

Could it be the cash register was put into the back room because it needs repair? And somebody spilled a Diet Coke all over it and, you know, they need to clean it off. There was a hurricane in the area, right? There's a billion reasons that it could not be working. And without that context, I don't care for AI or not, you're not going to know what the right answer is for you here. One of the things that we do a lot with events, but I recommend this just generally is, as you would think about shipping data, think about adding as much context as you possibly can along the way. Where was this? What happened? What other things were there as well? So they can correlate those signals together, don't wait until it gets to the back end where you're unpacking

and trying to do archaeology on this data. Instead, do the work on the front end. It may mean shipping a little bit more data, but your data science team, future you is going to be so thankful because your answers and responses just to be that much more accurate. What's interesting when you talk about this, I'm glad that you're going to solve the time zone problem because it's a perpetual challenge for me with the that I travel. Am I booking this appointment for local time or where I'm going to be? And all kidding, aside, I know that this represents massive problems to organizations, really serious problems in terms of lack of context. What do you see are those serious problems

and how do you see teams failing to build and scale modern data systems to account for this contextual issue? Yeah. When we go out, we've tried so many different ways to reach out to customers try to figure out what the biggest impacts were. And I thought that, you know, one thing that we do expansive is like, you could spend 20 minutes with us and we could save you 20% off your observability bill, right? Or your logging bill. It really is not a guy in a commercial. It really is that fast to save you that much time and money. I thought that was going to make a dealer's to pray, right? Turn to know. I mean, people are like, oh, that's nice, but could you just make it easier to debug? Like, I spend 50 plus percent of my data science team.

just doing work on cleaning the data. And it's not even necessarily messy data. Here's a real world story from an energy company that we're working with. They have two wind turbines side by side. Each wind turbine is putting out data. And they were installed about a year apart, same model, but it turns out the firmware for one is different than the firmware for the other. And what they did was they inserted a column in the data.

And as a result, the data from one breaks the pipe. like why from the data from the click, right? The data coming off this, I know we're in the future world of AI and what about. The data that comes off this is comma separated single straight, right? I am not exaggerating. It is that boring. And so you add a column, right?

Everything runs off the end and so on and so forth. So you need to figure this out. What we do with Expans Open again, anyone could do this. We just make it really easy is we push a lot of the data cleaning and thematization and structuring to the left. So we say, hey, you know what? We're not bringing to even get in this pipeline,

this overall system that you're building. We let you apply a schema. We say, hey, this doesn't match the schema you told us. So we'll send it to this other category for you to go investigate later. We allow you to group and aggregate up front. So maybe you don't even pass through raw data. You said that off to some archive bin, but you send only clean data. and we help you add metadata and monitoring up front.

So you can say, hey, you know, the reason you didn't get data the past day is because no one came by or the winter might never turned on, not because your data pipeline was broken, which again, I tell anyone who's, you know, worked with data in the past, either you have had a system where you didn't get data for three days and didn't know about it until you finally checked your dashboard to figure out what was going on or your wife. There's just the amount of monitoring and things around the pipelines is so broken. And what I recommend for everyone is you need to treat your data pipelines just like any other binary code. It's not just this fire hose that you hand when you get to bronze tier.

You need to think about it the moment the data enters your system to add the context, to add the information necessary that you're going to need downstream. Because trying to recreate it later almost guarantees you're going to miss something. Now, this is awesome. But the other thing that's going on is data has becoming much more dynamic. So once you add that context, how do you ensure that it's live and kept up to date through time? What's the technique there? Well, I don't think there's any exceptionally good way to do this, right?

I think the best, there's an open source project that I'm working on right now. it's called Makoto. It's use U-S-E-M-K-K-O-T-O-D-D-Ev. It's completely open source. It's completely apt-chitu. And the idea is assume that data will break, right? Assume that things will fail later. The best you can do is accelerate time to discovery by wrapping the start of your data pipeline with metadata, right? It's structured, slightly, clean metadata. And if you do nothing else, would say, hey, you know what? Here's the schema, as I understand it.

I'm going to use this schema. I'm going to enforce this schema. And here's the source. Then I got it for the date, the time, the schema version I enhanced. And I'm going to pass that all the way through, right? And that's it. That's the best you can do. Yes, there are many things you can do.

There are wonderful libraries out there, Pidentic and others that do schema data enforcement for left. I strongly recommend using other open source projects like Jason schema to give you a strong structured schema and things like that. But the real world is messy. The real world will break. Your data catalog will be out of date at one point or another, guaranteed. There's no 99%. One hundred percent guaranteed it can be out of date. The best you can do is when you discover that, 17 steps down your ETL line, say, oh shoot, this is already broken. Where do I go to figure it out?

And you have at that point, a piece of metadata that takes you all the way back and say, hey, you know what? I ingested this on this date from this wind turbine in central Ohio. Like there it was. Again, we're not solving the problem, but we're shortening the time to discovery. And truly, that is your best bet, rather than trying to institute a completely hard and fast gatekeeper. You know, this space of observability is something that's very close to my heart.

As a former silicon person, I love telemetry data, and I love for being able to measure and provide context for what's going on at systems. And then obviously, in the data layer, becomes very interesting. I guess one question that I have for you, we've been talking about observability and metadata governance for a long time. And a lot of companies have invested heavily in here. Is there something that you see? that's a repeatable thing where those efforts tend to fall short.

And maybe are there more effective approaches that are emerging, especially as we scale in the way that you do this right? So it's a really interesting question. And unfortunately, you're asking questions like, how long is a piece of string? Not wrong. Unfortunately, it does tend to be so situationally specific, right? Okay.

If I was doing a temperature sensor for a building or something like that, Each temperature sensor is only whatever, I have no idea, 100 bytes, right? If something is wrong about it, probably going to be pretty easy for me to figure out what's going wrong. So, you know, right? Exactly. Exactly. On and off, here's the temperature. You're done, right?

And yeah, if they added a column or something like that, maybe something broke. My life, it's pretty easy to recreate and the volume is not that big and so on. The most wrong approach is I will wait until it's centralized. to begin, right? Obviously, I'm talking my own book a little bit here, but if you wait until it gets to bronzed here, God help you. The amount of stuff coming in and so on, you are just going to be in a bad shape. And I will say this, the observability companies of which we are partners with, almost all of them, don't want this either, right? Even though you pay them a lot of money, and it owes a lot of money to store everything. They don't want that. They would much rather you come in

with clean, well-structured, the right cardinality, whole bit, right? They want that up front. But the attitude today is central observability team owns this. They've given me a bunch of APIs. I'm just going to use their APIs in order to get in. I'm not going to do any work beyond that. And then once it gets there, I'll run snow pipes or all run airflow or whatever to go and finally clean up the data and structure and so on.

And again, that is not badmouting any of those tools. They're wonderful. but you've got to do the work up front. Clean up a little bit. Apply some structure a little bit. Be smart about how you ingest and move the data in. Be segmenting. It's okay to do these things in a way where it involves a little bit more work on front,

but it pays off in spades later. And the interesting thing at Google, a lot of people don't know this, everyone thinks we tracked everything and we follow everyone everywhere. I'm telling you, raw data, raw lawns, raw, anything about any human being lasted unless you had specific legal authority. It lasted seven days maximum. And it was restricted to the smallest set of people and processes you can possibly imagine. Almost no.

There was some other stuff that lasted a little bit longer, but it was totally anonymized and stripped and everything like that. But the reason they had to do this was because if the raw stuff gets into your data lake, your bronze tier, right? It's like peeing in a pool, right? Like, all right, there's a little bit of pee in the pool. Am I ready to go in? You kind of like hold your nose. How much is pee is too much pee?

When I'm not willing to swim? It turns out with data, it's really small because just a little bit can interrupt your entire organization and caused Dayton's team to break and sell it. My recommendation is treat raw data like a toxic waste of, don't let it get anywhere new for your bonds tier, even if it is nothing more than shipping the raw data but are wrapping and in metadata and say, where it came from and let you peel it out later,

you're going to be so much happier, so much happier. But yeah, it is very situationally specific, but I've never ever seen anyone regret adding contact. text before you move your raw data. Edward. So David, final question for you, when you look at Expanso and you think about what you're trying to accomplish at the company, what does success look like in the next year or two? What do you want to accomplish with your customers? And how does this change the complexity of what we just talked about?

If I did nothing more with Expanso than everything I just described, right? Like, your developers, your agent engineers, so on and so forth. Just make their systems better and smarter because they're cleaner, they're able to focus on it instead of debugging why this particular Python library couldn't unpack this particular date time format, which they spent a lot of time doing. I'm a happy person, right?

We help them, we wrap this data, I think that's hugely valuable. That said, I am a startup founder. I've never been known to watch for ambition. When Jensen from Envena goes and stands on stage and holds up a $249 device, that could appear in any physical location of the world. I want us on that.

We run machine learning models. We run data pipelines. We run everything. We could be on trillions of devices and help, we'll adopt, use, and so on and so forth. So huge fan would love to help make that reality a thing. But both that, both taking people, factories, manufacturing, vehicles, multi-cloud, on-prem, blah, blah, blah, blah, blah,

helping them adopt the future, but also helping people with reams of data today that have no idea what to do with it, right? We're in partnership with a couple of folks right now who are doing some manufacturing work, and they have no IT staff in each of five different plants. Each plant is generating way too much data today. It is overwhelming their entire upstream bandwidth, so they're not living it, just sitting there. And a case, Usually I have someone walk over, check some machines, make sure stuff is working or whatever. But the other than that, this data just doesn't even exist for their organization. And it could and it should.

It would cut costs. It would save money. And it would save developer time, save engineering time, same floor engineer headaches and so on and so worried. If they could do that, I would love to participate in that as well because that's what we do, right? We help shape the data, streamline it before you move it. So you're not moving all this for our data. You're moving just what's important and necessary. So we help with that. So I don't know. Anywhere you have a bit of compute, I think Expanso can sit and help you do what you're doing today, better, faster, cheaper. But I try to be very tactical about it and satisfy the customers we already have and expand to brand new customers as they discover this particular element.

I can't wait to see how Expanso grows. One final item. And I want to thank you for being on the show. where can folks find out more about the solutions you're delivering and connect with your team? Absolutely. So the best place is expanseo.io, eXP-A-N-S-O.io. We have tons of examples. We've open sourced hundreds of examples and documentation, of course. We have scenarios and so on. And we do a lot of stuff. You can go. You can try it out for free right now. First five nodes free. Go enjoy. And outside of that, we get many like industry-specific requirements. Please do. not hesitate to jump at our Slack or Discord or whatever it might be or reach out to me directly. My email address is on site.

I don't believe. I mean myself where you can certainly mail our general stuff. Tell us the industries that you need. And we're happy to help you map to your solutions that help make your company better as well. David, thank you so much for being on the program today. It was a pleasure. It was a pleasure. Thank you so much.

Thanks for joining Tech Arena. Subscribe and engage at our website, Techorina.Ai. All content is copyright by Tech Arena. Thank you.