How Tiger Data Makes Real-Time Databases Ready For AI Agents

WEBVTT
00:00:02.479 --> 00:00:03.279
Hey everyone.
00:00:03.520 --> 00:00:05.440
Really interesting chat set up today.
00:00:05.519 --> 00:00:20.079
We're talking about real-time data and what happens when agents start talking to databases with the true innovator and industry expert to say the least from Tiger Data, formerly known as Timescale.
00:00:20.239 --> 00:00:21.120
Mike, how are you?
00:00:21.440 --> 00:00:22.160
I'm great, Evan.
00:00:22.320 --> 00:00:23.120
Thanks for having me.
00:00:23.519 --> 00:00:25.120
Well, thanks for being here.
00:00:25.359 --> 00:00:34.640
You're a bit of a legend in the database industry, if I do say so, but tell us about your background and what Tiger Data does today.
00:00:35.200 --> 00:00:35.920
Sure, sure.
00:00:36.079 --> 00:00:36.960
I'm Mike Freeman.
00:00:37.039 --> 00:00:39.520
I'm the co-founder and CTO here at Tiger Data.
00:00:39.759 --> 00:00:41.200
I also wear a second hat.
00:00:41.600 --> 00:00:44.719
I'm a professor of computer science at Princeton University.
00:00:44.880 --> 00:01:14.159
And so I guess my background has largely been in distributed systems and databases and storage, security, working everywhere from content delivery networks to security protocols that probably secure a bunch of stuff on your phone to the last 10 years I've been with Tiger Data, formerly Timescale, as you said, where we build data infrastructure for industrial and other types of data.
00:01:14.319 --> 00:01:17.519
And it's been uh it's been a really great journey.
00:01:17.920 --> 00:01:19.120
Yes, what a ride.
00:01:19.280 --> 00:01:22.239
And of course, many of us were very familiar with Timescale.
00:01:22.319 --> 00:01:26.799
Why change the name to Tiger Data, besides being a cooler name, perhaps?
00:01:26.959 --> 00:01:29.599
What does it say about where the company is headed?
00:01:29.920 --> 00:01:30.159
Sure.
00:01:30.319 --> 00:01:34.400
So I think there's two parts of what kind of made the name change.
00:01:34.719 --> 00:01:41.840
The first is that, you know, timescale db or timescale is a great name for a time series database.
00:01:42.400 --> 00:01:43.519
And there's two things with that.
00:01:43.680 --> 00:01:47.439
One is we are now more than just a time series database.
00:01:47.599 --> 00:01:58.159
You know, we're now serving people in in AI, in a broader uh data layer for industrial data, in in in the cloud, that's really increasingly great for agents.
00:01:58.400 --> 00:02:06.799
But more than that, people actually also sometimes had the wrong view of what we meant as a time series database.
00:02:07.040 --> 00:02:21.919
And in some sense, we were always people's main operational database that included both their time series data, sensor data, fintech data, event data, and their their business and application data.
00:02:22.000 --> 00:02:28.319
And in fact, one of the key reasons people found it valuable is both those things came together in the same database.
00:02:28.479 --> 00:02:35.439
And that was different from a lot of other, let's say, oper Prometheus, what you might use for observability data.
00:02:35.599 --> 00:02:44.319
For those types of settings, which people sometimes also called time series databases, it's really only about that application monitoring data.
00:02:44.479 --> 00:02:49.599
And it's not part of this broader operational database that you're actually trying to build.
00:02:49.680 --> 00:02:58.960
And so it kind of created confusion, I think we found in the market when people thought of the role we played much narrowly, much more narrow than we actually did.
00:02:59.680 --> 00:03:00.240
Got it.
00:03:00.479 --> 00:03:05.840
And you know, as a as a platform, Postgres has been around forever, it seems.
00:03:06.080 --> 00:03:11.039
And it's still in conversations about AI, it's having quite a moment.
00:03:11.120 --> 00:03:12.319
What why is that?
00:03:12.719 --> 00:03:14.080
I mean, I think there's two things.
00:03:14.319 --> 00:03:19.520
One is that, you know, a lot of people, you just want your database to work.
00:03:19.759 --> 00:03:25.039
And, you know, Postgres has, as you said, has been around for almost 30 years.
00:03:25.280 --> 00:03:30.800
And it has become, you know, in some sense, the trusted data layer for a lot of people's applications.
00:03:31.039 --> 00:03:42.479
The second big part that I think you know really created this second wave of adoption of Postgres is about 15 years ago, it started building an extension framework.
00:03:42.719 --> 00:03:48.719
And what the extension framework allowed it to do is it allowed the core of Postgres to continue to evolve.
00:03:48.879 --> 00:03:56.479
But you know, evolve, I would call it in a methodical, trustworthy, but let's say focused way.
00:03:56.560 --> 00:04:03.680
You know, you want it to continue to build a high reliable core, much like you think your operating system builds a highly reliable core.
00:04:03.840 --> 00:04:25.600
But then through this extension framework, which is what allows Timescale DB to exist in the first place, as well as vector databases like PG Vector, now PG Vector Search, uh, GIS databases like PostGIS, and lots of observability things, it allows the whole network to somewhat innovate around, you know, what are other things that we could build on top of it.
00:04:25.759 --> 00:04:33.759
And then Postgres can continue to be the data layer that basically serves all these different use cases.
00:04:34.079 --> 00:04:48.319
And so for many customers, they don't have to start saying, or many developers, they don't have to start saying, let's go out and let's get five different databases and let's build data pipelines and let's worry about the consistency and think about how these integrate.
00:04:48.480 --> 00:04:53.839
They basically could say, for you know, 95% of the use case, Postgres is all I need.
00:04:54.720 --> 00:04:55.199
Got it.
00:04:55.360 --> 00:05:10.319
And you mentioned the use cases, you know, data from sensors and IoT devices, power grids, financial systems of various kinds, which of course have been around for decades, but we're we're moving exponentially now, it seems.
00:05:10.720 --> 00:05:14.720
What's so difficult now about managing data at that scale?
00:05:15.120 --> 00:05:15.439
Sure.
00:05:15.600 --> 00:05:22.079
So I mean, I think this touches a little bit on our own our own journey at Tiger Data, is that we start about 10 years ago.
00:05:22.160 --> 00:05:26.240
We were starting at the time when consumer IoT was popular.
00:05:26.399 --> 00:05:30.720
And so we saw this, you know, kind of explosion of consumer IoT devices.
00:05:30.800 --> 00:05:34.399
And of course, this is all basically generating the sensor data.
00:05:34.480 --> 00:05:37.759
You know, you keep continuous streams from lots of different devices.
00:05:38.000 --> 00:05:46.399
You often also want to have that business data, that metadata around where these devices are, who's using them, et cetera, et cetera, which makes it valuable.
00:05:46.720 --> 00:05:48.720
Fast forward today, you know, what's even different today?
00:05:48.800 --> 00:05:58.959
And I think I think it's it's for a long time the industrial data, you know, data environment kind of developed differently.
00:05:59.199 --> 00:06:12.319
And one of the ways they developed differently, it was it was really designed, it didn't take an IT flavor, you know, saw a computer science, a software engineering flavor in the way we've come to build modern systems.
00:06:12.639 --> 00:06:13.759
What do I mean by that?
00:06:13.920 --> 00:06:27.040
You know, you think about modern systems, you think about these layers of your architecture, your database layer, your application, you build them somewhat separately, you use different technologies, these could fail scale independently, be very flexible.
00:06:27.279 --> 00:06:33.439
And in a lot of the industrial market, they were really kind of built almost like a 1990s appliance.
00:06:33.600 --> 00:06:39.279
There was one big application, one big box that probably ran on Windows in some closet.
00:06:39.439 --> 00:06:41.600
And that box basically tried to do everything.
00:06:41.680 --> 00:06:53.360
It had storage, it had protocol conversions from all these industrial protocols, it had compute and analytical processing, it had visualization, it had alarms, it had everything.
00:06:53.680 --> 00:06:56.240
And it worked up to a scale.
00:06:56.399 --> 00:07:10.560
And the problem with these things is these, I mean, the reason why most modern software systems aren't built like this anyway, is as you want to do more and more, they really lock you into this very limited subset of what they can do.
00:07:10.800 --> 00:07:18.079
And so that's bad for you know, you being able to innovate, you be able to do more things, you're kind of locked into what they build for everybody.
00:07:18.240 --> 00:07:24.319
You're generally locked into these proprietary systems and they're increasingly getting more expensive every year.
00:07:24.639 --> 00:07:29.199
And they also don't scale very well and they don't really handle the new volumes.
00:07:29.360 --> 00:07:35.040
And so, if you think also about what's happening with the broader industry, it's a really exciting time.
00:07:35.120 --> 00:07:37.519
You know, America and the world is building again.
00:07:37.600 --> 00:07:49.439
We're building data centers, we're building energy, we're reindustrializing manufacturing and pharmaceuticals, and all those things mean more industrial data every year, and we need a better place to store it.
00:07:49.600 --> 00:08:04.319
And so this emergence of these kind of new modern historians, where they're separating, let's say, the compute side and the part that speaks these industrial systems with the data storage side, which is what TimescalDB is really great at.
00:08:04.399 --> 00:08:09.600
And I think that's really the future for a lot of these, for a lot of these uh industries.
00:08:10.160 --> 00:08:10.879
Fantastic.
00:08:11.040 --> 00:08:15.120
And you've also been talking a lot about agentic Postgres.
00:08:15.439 --> 00:08:24.160
You know, why does an AI agent need something different from a database than you know, a traditional developer might might use?
00:08:24.639 --> 00:08:24.959
Sure.
00:08:25.120 --> 00:08:30.560
I think the big thing, you know, when I think of agents, you know, they sometimes act like developers.
00:08:30.800 --> 00:08:33.519
They're just much faster at doing it.
00:08:33.600 --> 00:08:37.600
You know, they could work 24-7 and they could do lots of things in parallel.
00:08:38.080 --> 00:08:54.960
And if you think about where a lot of agentic development is going, it's it's basically how do we build system infrastructure that allow that gives access to data, access to our services to agents in a safe way.
00:08:55.200 --> 00:08:58.879
So obviously, we don't want to let them let them go crazy on prod.
00:08:59.200 --> 00:09:01.279
We give access the same way, safe way.
00:09:01.440 --> 00:09:13.039
And we often want to give them a snapshot of what is actually our real data, or maybe massage in a careful way for security reasons, because they make better decisions when they have real contexts.
00:09:13.279 --> 00:09:16.799
And often we want to give many of this in parallel.
00:09:16.960 --> 00:09:24.000
Because one of the things that we found that agents are actually quite good at is they're good at this whole notion of a chain of thought or agent swarms.
00:09:24.080 --> 00:09:27.759
They're good at basically breaking down problems and trying to solve them in parallel.
00:09:28.000 --> 00:09:31.840
And so when you think about we've been innovating of various things to support agents.
00:09:32.000 --> 00:09:37.120
One is to build what is effectively now the default search stack for Postgres.
00:09:37.919 --> 00:09:40.799
So there's lots of ways that people build search.
00:09:41.120 --> 00:09:50.000
Everybody started with vectors, and now kind of the motion has been towards this notion of hybrid search where you include tech search, a keyword search and vector search and whatever.
00:09:50.080 --> 00:09:58.559
And we've basically, through that extension framework I talked about before, we've basically built the tech search stack for Postgres, which is now running on all the major hyperscalers.
00:09:58.639 --> 00:10:05.519
It's it's it's our extension running on them, as well as kind of like the most advanced vector search part for Postgres as well.
00:10:05.679 --> 00:10:11.200
And so one is we now in your database give agents a way to easily search for stuff they need.
00:10:11.360 --> 00:10:14.240
But the second thing is the framework is we want to make it easy.
00:10:14.399 --> 00:10:16.639
We know there's lots of value in your database.
00:10:16.879 --> 00:10:23.840
We want to make it easy to just spin up a copy of a database and not just like spin up a you know a hundred meg database.
00:10:24.000 --> 00:10:38.559
We want you to be able to take your terabyte-size, 10 terabyte scale database and within tens of seconds have a have a have a fresh copy that doesn't cost you any extra storage to run and give it access to your agent.
00:10:38.720 --> 00:10:44.799
Your agent could could run queries on it, play around with it, whatever, and spin it down at almost zero cost when it's done.
00:10:44.960 --> 00:11:06.639
And so that's been a lot of innovation we've been doing with with our with Tiger Cloud, is we we're calling it fluid, this this fluid storage and fluid services, where we make it super easy for agents to get these almost instantaneous branches of their database in a way that doesn't take any extra storage and allows them to safely play with it and then and then and then spin it down as needed.
00:11:06.720 --> 00:11:16.080
And I think we're seeing that across the industry, that we're we're rethinking at every port of the stack, what does the system infrastructure look for agents?
00:11:16.240 --> 00:11:21.600
We just happen to be doing it obviously for for the database, which is a core part of a lot of applications.
00:11:22.399 --> 00:11:23.279
Amazing.
00:11:23.519 --> 00:11:29.279
And so how does that tie into MCP, which is another great innovation in the industry?
00:11:29.519 --> 00:11:31.600
How will it change MCP?
00:11:31.679 --> 00:11:39.759
That is the way developers and AI coding tools interact with their databases and and how are you supporting all those requirements out there?
00:11:40.159 --> 00:11:45.679
Yeah, so Timescale and Tiger are are both have MCP servers and all those things.
00:11:45.840 --> 00:11:49.840
I I think, I think, you know, broadly there's there's two aspects though.
00:11:49.919 --> 00:11:58.000
And I don't think it's it's perhaps specific to MCP as much as like what does the interface to an agent look look to infrastructure.
00:11:58.320 --> 00:12:05.360
And you know, what we've I think discovered in the last year, this is an industry obviously moving very fast and a lot of technical innovation.
00:12:05.519 --> 00:12:16.320
But what we've discovered the last year is that you obviously want to give access to agents to have tool calling, the ability to call and execute tools in a safe way.
00:12:16.720 --> 00:12:22.399
And, you know, how how can agents be good at learning what tools they give?
00:12:22.639 --> 00:12:32.000
MCP is one way where every tool call includes a human description of what the tool does and the agent knows how to, because they're LLMs, they know how to read that description.
00:12:32.159 --> 00:12:39.360
You could, of course, also give them CLI commands or other APIs which which with documentation they could they could all parse.
00:12:39.600 --> 00:12:55.279
The important part is that we want to build infrastructure that is safe for agents to run, you know, run in a you know, sandboxed environment or a read-only environment or a way where you could do destructive behavior.
00:12:55.519 --> 00:12:59.360
It looks very similar to prod, but it's not going to affect prod because you want to protect it.
00:12:59.679 --> 00:13:04.080
And and allow the kind of agents to iterate and adapt.
00:13:04.240 --> 00:13:08.000
And the one thing that we do know about agents is actually interacting with databases.
00:13:08.159 --> 00:13:10.240
They're actually really good at writing SQL.
00:13:10.320 --> 00:13:20.000
You know, they've been part of the way these models, these foundational models, have been trained itself, is that they've been, they've been, you know, coding agents certainly have been trained to write SQL.
00:13:20.240 --> 00:13:22.960
So the important thing is they know how to write SQL.
00:13:23.120 --> 00:13:30.639
We then need to give them tools to control databases and to go control that context in a safe way.
00:13:30.960 --> 00:13:53.200
And, you know, in the end, allow them to basically both build applications as well as do the type of advanced analytics where humans can start just asking questions and the agents can go off and figure out where that data is stored, how to translate those human questions into code, into SQL and other type of things, and and somewhat get the answers that people want.
00:13:54.320 --> 00:13:54.960
Interesting.
00:13:55.200 --> 00:13:57.519
You also innovated with your own file system.
00:13:57.759 --> 00:13:58.720
Talk a little bit about that.
00:13:58.799 --> 00:14:03.120
What inspired that approach and what can you know people do with it?
00:14:03.519 --> 00:14:03.840
Sure.
00:14:04.000 --> 00:14:09.279
This is a more of a fun side project, if you will, for me than a than a whole company initiative.
00:14:09.360 --> 00:14:11.600
But you know, one thing I call it Tiger FS.
00:14:11.679 --> 00:14:28.240
One thing I noticed was that agents themselves are really good at if you look at I should say the harness that a lot of uh agents run in, like Claude Code and and and and and the like with codecs and and and other other things as well.
00:14:28.399 --> 00:14:34.480
They've been trained, much like I said before, the frontier models have been trained to know how to write SQL, to know how to write code.
00:14:34.720 --> 00:14:45.039
The harnesses have often been trained or often post-trained to actually interact with Linux file systems or Unix file systems and tools quite well.
00:14:45.679 --> 00:14:51.200
And so the idea was like, we know that we have a lot of data in a database.
00:14:51.360 --> 00:14:55.200
Can we actually give them a file system interface rather than database interface?
00:14:55.279 --> 00:14:56.879
Could they do things interesting like that?
00:14:57.120 --> 00:15:03.200
Conversely, I was talking before about making it making it safe and reversible.
00:15:03.360 --> 00:15:08.960
You know, a lot of people are now pointing their agents at their local file system, having them edit files.
00:15:09.200 --> 00:15:15.440
They change the files, but sometimes the agents make mistakes or like, you know, I don't like that change, let's revert it.
00:15:15.600 --> 00:15:21.600
Today, what that typically is is the reverting is just telling the agent to undo the action they did.
00:15:21.759 --> 00:15:24.720
Sometimes agents get it right, sometimes they get confused.
00:15:24.960 --> 00:15:33.519
But from one some perspective, if you reverting as like an undo, this is low-level mechanisms that we've built into a lot of systems, right?
00:15:33.679 --> 00:15:49.440
You know, if you think about file systems, databases often have they keep logs of they keep records or right-ahead logs of actions, and then they have the ability to undo actions in kind of an item potent in a safe way.
00:15:49.600 --> 00:15:56.000
And so what I said is let's think about if you run our agent on a file system that is actually backed by a database with this functionality.
00:15:56.159 --> 00:16:01.600
And so you could kind of make your a file system interface that's fully undoable.
00:16:01.759 --> 00:16:20.639
And again, the whole notion of let's figure out how to make, you know, how to like let the let your agents cook and yet do so in a safe way because you don't want them to, you want to be able to undo the operations if you don't like it, or you want them to be able to work in snapshots or in safe ways that won't interfere with your production data.
00:17:05.410 --> 00:17:06.210
Interesting.
00:17:06.529 --> 00:17:18.130
So looking at the business side, you know, many companies are are, you know, large companies are siloed and they have separate systems or silos for applications and analytics and search and other use cases.
00:17:18.289 --> 00:17:26.850
That another lifetime I worked at Oracle, that was great for us because we we could sell a hundred different databases depending on what their their use case was.
00:17:27.009 --> 00:17:36.450
Why do you think that should happen more within inside or if you will, Postgres for you know obvious selfish reasons, but other reasons as well.
00:17:37.170 --> 00:17:46.930
Yeah, so I don't think it's that all, you know, I don't think that analytics and operational databases are are going to disappear.
00:17:47.250 --> 00:17:56.770
I think what the way I would frame it is that I actually think that you know, we're focused on operational, operational use case, let's say.
00:17:57.170 --> 00:18:02.850
And I think the nature is not that search doesn't exist or large-scale machine learning.
00:18:03.010 --> 00:18:11.570
There's a reason there's there's cloud, you know, there were data lakes, then there's cloud data warehouses, now they're Lake House, and and you know, Databricks and Snowflake are both successful companies.
00:18:11.810 --> 00:18:17.810
I think the issue is that your operational data is more than just what used to be called OLTP data.
00:18:17.890 --> 00:18:19.330
It's more than just your bank balance.
00:18:19.410 --> 00:18:22.610
Your operational data now is analytical data.
00:18:22.770 --> 00:18:24.290
It is search, right?
00:18:24.450 --> 00:18:37.170
So doing a search at the, let's say, at the enterprise level where you have petabytes of things and you want to do reporting is very different than writing a search interface to a customer-facing application that powers your website.
00:18:37.250 --> 00:18:47.810
You know, faceted search that powers Amazon, let's say Amazon shopping is not the same problem as a back-end system that is trying to, you know, process petabytes of data.
00:18:48.050 --> 00:19:07.570
Similarly, building real-time control loops for industrial systems or building dashboards, you know, to in real time see how data centers are operating, see how energy systems are operating, is not the same thing as building machine learning in Databricks or doing large-scale uh reporting off of Snowflake.
00:19:07.730 --> 00:19:13.650
And so I do think that those are actually serving two different use cases, often with different types of people.
00:19:13.810 --> 00:19:18.610
Over here, you have developers and kind of operators.
00:19:18.770 --> 00:19:23.010
And over here, you have analysts and data scientists.
00:19:23.170 --> 00:19:31.330
And I think what is useful is not to say, you know, one type, I think often the same type of data serves both use cases.
00:19:31.570 --> 00:19:37.250
What we're saying is how do we deliver this use case about operational use cases?
00:19:37.410 --> 00:19:43.490
You know, how do we deliver that in a in a easy, scalable, straightforward way?
00:19:43.730 --> 00:19:56.930
And our answer is that, you know, it's it's not good for anybody when you need to build 10, when you need to grab three different, four different databases to basically deliver the same application in the exact same use case.
00:19:57.250 --> 00:20:12.130
If we could achieve that all with one database, you know, it is easier to operate, it's more consistent, more reliable, and in general, and more flexible, and therefore we'll accelerate what both developers and frankly what agents can can do.
00:20:12.850 --> 00:20:13.730
Fascinating.
00:20:13.970 --> 00:20:17.650
So looking ahead, I won't ask you where we'll be in three to five years, I think.
00:20:17.810 --> 00:20:18.290
Who knows?
00:20:18.450 --> 00:20:19.330
None of us know.
00:20:19.570 --> 00:20:21.330
But what is next for Tiger Data?
00:20:21.410 --> 00:20:23.330
Can you give us a peek into the future?
00:20:23.410 --> 00:20:26.690
What should we pay attention to in terms of trends and opportunities?
00:20:27.090 --> 00:20:27.330
Sure.
00:20:27.490 --> 00:20:43.170
So what's what's interesting for us, I think of this a little bit as uh back to the future, or maybe the future is is the past or something, in that you know, a lot of companies, especially database companies, start on-premise, build a large enterprise business on premise, and then move to the cloud.
00:20:43.250 --> 00:20:45.170
You mentioned Oracle, that's certainly the case.
00:20:45.490 --> 00:20:50.290
Mongo, you know, many of these companies started with their on-premise business and eventually built the cloud.
00:20:50.610 --> 00:20:57.330
We started the opposite way, in the sense that, like from early on, Tiger Data, then Timescale launched in 2017.
00:20:57.570 --> 00:21:01.810
And, you know, we initially spent some years building what was our open source part of our database.
00:21:01.890 --> 00:21:05.890
Then we launched our Tiger Cloud in 2019, 2020.
00:21:06.050 --> 00:21:10.770
And since then, we have thousands of customers, thousands of production customers running cloud.
00:21:10.930 --> 00:21:12.530
But we always had that open source.
00:21:12.610 --> 00:21:18.930
And we started seeing people deploy it more and more with these industrial control systems on the edge.
00:21:19.090 --> 00:21:23.410
That is, you know, running factory floors on oil rigs, deep in mines.
00:21:23.570 --> 00:21:28.690
Now it's running in the AI neo clouds and in AI data centers and all the power surviving it.
00:21:28.930 --> 00:21:36.610
And really in the last year, we realized that there was this large opportunity for us in that they were all stealing a DIY, they were taking open source.
00:21:36.690 --> 00:21:43.410
These are these are controls engineers, they're trying to build reliable systems with you know, patching these things together.
00:21:43.570 --> 00:21:45.090
And they were really struggling to do so.
00:21:45.250 --> 00:21:51.650
They were struggling from a scaling performance, from an enterprise grade reliability, and from the build to operate entire systems.
00:21:51.810 --> 00:21:59.490
Because these are now, I mean, these are some of the largest, you know, factories, largest control systems that humanity has ever built is this future.
00:21:59.570 --> 00:22:04.050
What the, the, the, the building that we're doing as part of the AI build era right now.
00:22:04.290 --> 00:22:16.690
And so what's really been exciting is in the last year, we've launched what is Timescale to be enterprise, which is our on-premise deployment of Timescale to be in Postgres to serve all of that data.
00:22:16.930 --> 00:22:27.170
But you know, it's not that we're trying to go back into like the private data center that's running in a bank, it's that we're deployed co-located often with the industrial systems that's being monitored.
00:22:27.490 --> 00:22:31.490
So some customers have 50 factories that's all coming back to a central point.
00:22:31.650 --> 00:22:34.370
We're in those 50 factories and we're at that central point.
00:22:34.530 --> 00:22:54.770
Some of our largest scale AI data centers with you know a dozen data halls and buildings and campuses, these are facilities that Cost tens of billions of dollars of CapEx to build, plus the gigawite energy that they build of solar and BES and LNG and all these things that is really being built out for this future.
00:22:55.010 --> 00:22:56.530
That also is a control system.
00:22:56.610 --> 00:23:04.530
And that's an industrial control system, much more than our than our air-cooled CPU-based data centers were ever before.
00:23:04.850 --> 00:23:19.330
And as part of now what is storing all that industrial data, we find ourselves, timescale to be, as part of the control side, the OT side of that next generation factory that I think, frankly, is powering most of our growth.
00:23:19.490 --> 00:23:30.290
And so I find that a really fascinating stuff, both with the scale of data and the massive innovation that's starting to happen in all of these sectors and in energy and manufacturing, whatever.
00:23:30.450 --> 00:23:32.370
And it's a really exciting place to be.
00:23:33.010 --> 00:23:34.050
Exciting indeed.
00:23:34.210 --> 00:23:58.290
Well, just a side question, if I could, given your deep connection to Princeton University and history there, what is your advice to undergrads, to graduate students, even you know, youngsters, I call them in 20s, on their careers, uh and interest in computer science and and innovation in AI and beyond, given all the change and disruption and media stories we're seeing.
00:23:58.450 --> 00:24:01.090
Any any words of wisdom you can offer them?
00:24:01.410 --> 00:24:02.290
I think two things.
00:24:02.450 --> 00:24:07.810
One is I know there's a lot of let's call doomerism about the future of jobs and whatever.
00:24:08.050 --> 00:24:16.450
I am still very bullish on on both AI as technology and what it could do for humanity and also even what it means for jobs.
00:24:17.170 --> 00:24:19.170
Clearly, there's gonna be disruption.
00:24:19.410 --> 00:24:28.290
I also think that what it me will mean to be a developer in a computer science five years from now is gonna look very different than what it meant, you know, five years ago.
00:24:28.530 --> 00:24:32.530
But you know, with all of these technologies, you know, people have to adapt to the change.
00:24:32.690 --> 00:24:35.970
This is one thing that I've always thought certainly I'm not unique to this.
00:24:36.130 --> 00:24:38.690
Humans are really good at adaptation.
00:24:38.850 --> 00:24:41.810
And so I think the best thing that young people can do is two things.
00:24:41.970 --> 00:24:50.610
One is I do think it's useful to understand the core, you know, build a deep understanding of technology.
00:24:50.850 --> 00:24:52.050
And, you know, this is true.
00:24:52.130 --> 00:25:02.690
If you look at a place like Princeton and and other research universities, we never taught technology, we always taught concepts.
00:25:03.010 --> 00:25:07.810
And one of the reasons they do that is the technology, you know, we're not going to teach a software library.
00:25:07.890 --> 00:25:12.770
The software libraries will change, but the underlying concepts do remain.
00:25:13.010 --> 00:25:18.290
And it's funny, like we still teach actually people how how to write assembly code in one class at least.
00:25:18.450 --> 00:25:25.890
Now, I don't think I've written assembly code since I was an undergraduate, but I think it's supposed to teach concepts about abstraction and how computers work and whatever.
00:25:26.050 --> 00:25:29.570
And so I do think it's still important that people learn concepts.
00:25:29.810 --> 00:25:32.690
The flip side is it is inevitably true.
00:25:32.850 --> 00:25:44.690
And as we look to build teams and hire, I think the best thing people could do is lean into their use of AI, trying to figure out how it's it's it's changing and kind of be ready for the roller coaster.
00:25:44.770 --> 00:25:47.010
Things will look very different three to five years from now.
00:25:47.170 --> 00:25:58.770
But I think the best things that people can do is to be open and flexible and and kind of intellectually flexible and malleable on how they adapt these technologies.
00:25:59.010 --> 00:26:07.170
And I think we'll we'll come out of this at the ability to do more cool things with software than we've ever been able to do before.
00:26:07.570 --> 00:26:08.050
I love that.
00:26:08.130 --> 00:26:11.490
Well, on that very positive, optimistic note, thanks so much for joining.
00:26:11.570 --> 00:26:14.130
I learned a lot and onwards and upwards.
00:26:14.450 --> 00:26:15.490
It was a pleasure, Ovan.
00:26:15.650 --> 00:26:16.130
Thank you.
00:26:16.370 --> 00:26:17.490
Thanks so much.