Transcripción completa de How Tiger Data Makes Real-Time Databases Ready For AI Agents

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.