 you shouldn't have to think about your disk allocation or disk storage, right? It should just scale with you and you should in fact pay for what you use. So that's actually what we do with timescale. Hi, this is Osupal Bhartiya and welcome to another episode of TFR. Let's talk today. We have with us Mike Friedman, co-founder and CEO of Timescale Mike, great to have you on the show. Nice to be here. I will talk a bit about a broader picture when it comes to data databases is that if you look at modern, it could be cloud native or Kubernetes word. Talk a bit about what are the challenges that folks are facing because folks have moved to when you look at Kubernetes Clarity production. Of course, it's very easy to get up and running. Historic is cheap. That working off course, the problem solved. But when it comes to data and databases, what are the major challenges that you see enterprises or even startup surfacing today? So if you think about where a lot of Kubernetes and different elastic services started out, it really started by the shift of how we want to build stateless applications. It was the next generation of how we build web tiered where that was focused a lot of times so you could spin up services, spin down services. And the key idea there was that they didn't need to worry about state because all that state was in our databases. But now we have the problem of we actually want to build now more robust and reliable databases. So you had all this infrastructure, which is great at building super elastic stateless services. But it didn't solve what are really the underlying infrastructure for building modern applications, which are databases. And so why does this happen? This happens because users and customers, whether or not our business or consumers are really demanding more and more from our applications. We want them to be faster, more engaging, more personalized. And what was great is that we have these big hardware trends, Moore's law and Criter's law and all these things that computer stores were getting cheaper. But the question is, how does that bring better productivity to developers so they could build better and more engaging applications? I think that's really what happened. You've seen this new age of very interesting databases and databases companies emerge. I think time scales are the greatest example of that. We're really thinking about how do we re-architect the database for modern applications? And so what do I mean by modern application? You know, it's data intensive. There's lots of ingest happening. There's events from your product and usage, metrics from device or sensors, other real-time data feeds. And then you want to build these applications that use all this data to provide live analytics or live data that's available to query immediately. This is not about BI reporting, which we thought about a lot of databases. That's often a different data team. This is about how do we enable developers who are building applications on top of this data? And so that's really what time scale focuses on. How do we, we're built, we think of ourselves as Postgres++, Postgres we are protected for modern applications. We make it easy, fast, scalable, worry-free and cost-effective. And so that if you really want to worry about, if you're today, you're trying to use Postgres or MySQL or maybe Mongo or other things and you're running into performance or scalability or cost reasons, that's how moving to time scale, again built on Postgres, but more for this modern applications and modern cloud. Now, if you look at, once again, databases, Postgres is a great example. I mean, most of these databases have been around for a very long time, almost all of them, these predate the cloud, cloud-native world. Talk a bit about what are the limitations that these databases don't have and once again, how time scale enters the picture and try to tackle some of those challenges. Yeah, so I think there's two aspects of it. One is, what is it about these database architectures themselves? Is that what we want? What assumptions do they make about the infrastructure when they were designed initially for running on a single server versus running in the cloud? And what about the workloads have changed? And because I think it's really all of those, it's that the deployment models have changed and the workloads have changed. And that's where time scale is focused. In fact, I think we're actually more unique compared to a lot of people playing in this space because we have teams that both extend the internals of the database as well as do a lot of really amazing engineering around the database and the infrastructure itself. So the interesting thing about a database, when we launch time scale, our launch blog post, this was 2017, is when boring is awesome. And what we mean by that is we started by saying, what about the cloud and it's stateless? We want a scale, but it sits on this database. And the thing is, if you're a developer, you want to focus on your application. You don't really want to think about your database. You want your database to give you everything you want, but you want to just work and you want it to be worry-free. It's kind of like your Wi-Fi. Like if your Wi-Fi is amazing, you never think about it. The times you think about your Wi-Fi is generally when you're really unhappy with it. And so I think that's been this tension in this industry. It's like we have databases take a long time to get right. The thing that people say is it takes at least a decade to make a robust database because it's okay. You can get the first 60 or 80 or 90 percent right, but it's the last 10 or 20 percent. Every 99 to 99.9 bit of reliability takes another order of magnitude of effort because it's all the long corner cases. And so Postgres itself is a database with its roots back in the 1980s or 1990s and academic work, but it's really been an amazing community effort of millions of person hours of work to get to the stage it is. And of course it's built very general purpose and because it's so community driven, it's by construction very general purpose because it really wants to run anywhere. It wants to run on a Raspberry Pi, in your old rack, in the cloud, whatever. And they make various decisions about they want to generalize it when as kind of a timescale where we focused on offering a managed offering, we could become much more opinionated for the type of deployments and the type of use cases that we're focusing on. So coming back to what I talked about with a modern application, one of the things we noticed is we started, we call this time series, but it's really much more broader than that. It's time series, it's events, it's analytics, where you have these streams of data. Well, there's different ways you'd even construct data structures inside your database if you're looking at workloads that are append mostly as opposed to workloads which are constantly updating the same records again and again. And so while we build on top of Postgres, some of our core has implemented what's called as an extension, but really we have hooks throughout the Postgres software that we line a layer on top of that. So we support all of what Postgres does, that's why I call it plus plus, but then all add all these new capabilities designed for what these type of modern applications are. Do this automated partitioning that's transparent. We have this amazing native compression, this hybrid row columnar storage, soon vectorized execution, these things of, you query the same thing again and again. So we build up what we call continuous aggregates which are basically materialized views that are constantly kept real time based on any changes you make to the database. All which is again how you serve modern applications. So I say that by saying you take this amazing thing that people work trust with all their production workloads and then you build on top of it and extend it for the type of use cases that people are trying to build today, especially those that are customer facing, as well as in type of cloud environments which we hadn't had before. As you're saying that developers should not get overwhelmed with things like databases, in general, these developers should focus on writing business application and should not have to worry about a lot of this plumbing, there's the whole idea of the cloud in the beginning, and you know what, we can take care of your lab stack, you don't have to worry about debuance or sent away as a rel, you just focus on that. But now if you look at Kubernetes or cloud, you're spending most of your resources on actually managing them then actually focusing on business application. I totally agree. And let me give you an example. Like, and you think about something like RDS, RDS is really like, it was just a lift and shift, lift and shift, right? They took Postgres, they just run it in a VM and that's kind of what RDS is. And some of the things that we're doing in the cloud, for example, is that, you know, you shouldn't have to think about your disk allocation or disk storage, right? It should just scale with you and you should in fact pay for what you use. So that's actually what we do with timescale. Like, we worry about making sure that you have enough storage underneath, but you know, you just write as much data you need. And in fact, I talked about compression before, you know, we see crazy numbers of 90, 95% compression on our data because we use actually algorithms designed for, you know, the types of data. If you have, you know, we were actually compressing different types of data differently to get those amazing rates. But, you know, you just store the amount of data they use and that's all you pay for. And another thing that we just, for example, launched again, this is what you could do when you're cloud focused is that if you think about this data that you're constantly writing into your database, you know, you probably use the recent stuff a lot, you probably query it a lot, you probably even update it. As the data starts getting older, especially maybe your data from a year ago, you still want it around to build analytics on top of, to be able to occasionally do ad hoc queries against, but you're probably not changing it too quickly. So in timescale, we allow you to transparently tier that across, you know, fast SSDs as well as S3. That's all transparent to you. You just look like you have this giant table with a policy on it. You don't actually think about that. But under the covers, we take your SQL queries. Some of that get executed in main memory on standard disk. Some of that gets transparently pushed down into S3. And again, it gives this bottomless management experience for the developer where they just get focused on their business applications and let all that, leave that all that complexity to us, but then reap some of those cost savings that we're able to pass on as well. As you're talking about some of these databases, they predate a lot of these cloud and technology, but a lot of new technologies, new databases, they have emerged in, which are like born in the cloud native word. Of course, we have started talking about Kubernetes in production like one or two years ago. Talk about somehow those databases, which, you know, once again, like at the very early stages, like you're also one of the biggest differences between application and databases is database or data is the actual asset of a company. Application can go and come back, you know, but the data, that is what the most critical piece there, and that's why it's important. So talking a bit about when looking at some of those latest technologies, what are the risks associated with them? Because once again, when we talk about cloud, we are not talking about a stateless workload. We are talking about stateful workloads. And, you know, like you said, I mean, what we are, the customers that we serve, and these directly we serve, you know, are building their production apps on this. You know, when we have customers where, when we stop, you know, we serve gaming companies. If our database isn't available, the game stops working for their millions of users. We serve IoT and manufacturing companies. If we're down, their manufacturing line actually stops. And so you can imagine that you need to, you need to really care about operations and stability, not only just the database and how we engineer, but, you know, we have supported ops in APAC and EMEA in North America, because we practice, you know, around the clock follow the sun models of all of our cloud infrastructure. But back to your question, you know, when we think about that, I started by saying when boring is awesome. And, you know, it takes a long time to build a mature database. And I think that was something that was somewhat unique about our approach is how do we make it Postgres Plus Plus as opposed to this, I think, false dichotomy, which says that either you have to use the old option, which is not modern, doesn't fit modern needs, or you have to start from scratch and build on top of a really nascent technology. And I think when you start from scratch, you know, you could build some early performance results that look good, but I think those solutions generally lack the maturity and stability and, you know, operational maturity and tooling and developer tooling and developer ecosystem as well established options. You know, I think lately you start seeing a lot of companies who become, you know, Postgres wire format compatible, but all that means is they speak a network protocol. That says nothing about their internals where it takes years to actually, you know, iron out those details. And so I think that leads to a lot of unexpected bugs, performance issues, even data loss that potentially disrupts business operations. And I think it's also that, again, it's not just the risk, it's that with a lot of newer databases, the problem with all infrastructure, it's that, you know, people share the same 60, 80% of use cases, but you always have that last 20%. And the problem is everybody's last 20% is a little bit different. And so it's really that amount of maturity that, you know, time scales through Postgres that we get this breadth of features and functionality that is powerful for our users, not just when they start, but as they scale their, you know, their business and their applications as they want to do more and more with their database. So I think, you know, it leads to, you know, performance stability. It leads to perform, you know, engineering productivity over time and also helps kind of reduce business risks when you could kind of modernize something like, like an amazing database like Postgres. Why Postgres? Let me start by saying is like, you know, I'm, that was one bet that we were so confident of when we started. And I actually think if you look at the trends over the last five years, there's all these metrics. It actually is that Postgres, this database that started late 80s, early 90s, that is actually today like almost the fastest growing database. And it has really caught this, you know, reemergence as the database that I think developers are going towards. So I think that decision we made when we started about, you know, six, you know, six, seven years ago, that is totally one that I'm very happy we made. And it was never really came in doubt. You know, I think that there's really, like I said, you know, stability feature function. But, you know, when you think about more, I mean, Mongo and influx, which you just mentioned are both, you know, more of no SQL databases. You know, they really kind of, you know, generally fall down. You know, there's no free lunches. You know, you have to actually think about, you know, it's good to think about data modeling a little bit when you think about building robust applications. But really, it's the power of SQL that we found really important. In fact, the backstory of timescale is when we started out, we weren't initially a database company and focusing on time series. We actually are building a platform for IoT for sensor data. And as you can imagine, IoT generates a lot of sensor data, which is time series. And we initially were looking at some of the open source offerings that offer time series databases, and some offered, like, you know, metrics. I'm going to store my device metrics. But what's important about your data is not just your metrics, but also information about the devices generating them, the business data, the metadata around those metrics that are emerging. So what we had to do, in fact, what we also hear a lot of customers who are using these not relational offerings, like Postgres, but other things, is they deploy both a time series-only database and a relational database, like Postgres. And then what you realize is whenever you want to answer questions, you need to move those joins to application space. So if you want to ask new questions about your data, you can't just query your database. You need to deploy new application code that then pulls this data from two different databases and then joins it in application space. So not only is that bad for performance, it's bad for productivity. It's operationally complex. And so the reason we actually started building Timescale, TimescaleDB on Postgres is it solved those needs. It gave us the SQL we want. It gave us the performance we want. It gave us that operational simplicity. And it basically stored both our time series events and analytical data, as well as our business and metric data. And we see that across basically all of our customers as well. As we are talking about these databases and technologies, I also want to talk a bit about the cultural aspect. When we look at, we talk about devos, disks or co-ops, sorry, spectrum engineering. A lot of disciples are there. A lot of processes are there. What kind of trend you're seeing when it comes to databases? You're like, hey, yes, we do need an organization-wide approach because once again, as you said, if the database is down or something goes, that's when everything is down. Or you're like, no, we don't need that. Companies, they are doing fine. Or you're like, no, developers or teams are looking at databases differently. Well, I think two things. One is not surprising. We view that kind of data is the life-flood a lot of these applications. So obviously care and maturity needs to be taken when building applications. Although I think part of the role of companies like Timescale is to hand a lot of that robust operations for users again so they could focus on their applications. But I think that one of the other trends that we see is that when people talk about databases, there's a lot of old terms that they use like OLTP and OLAP and HTAP and all of these things that are meant to describe the workloads. And some of those things became popularized, frankly, around because of benchmarks, like industry-standard benchmarks that existed DPCC and DPCH and all these things. But I actually don't think that's the right way to think about it. I don't think it's an OLTP workload or an OLAP workload or something else. What we see is that what really differentiates this is who the users are and what purpose that data is being used for. And so we see a big distinction between developers, often product teams, line of businesses, whatever you want to call them who are building applications a lot of times external facing, sometimes even internal facing, but they're building applications on top of a database. And that database has to be operationalized, operational, it's productized, it serves the core use of that data. And the opposite, which are often data teams or centralized data infrastructure, which you see more technologies like traditional data warehousing or data lakes or lake houses or whatever the amount of, there's also a growth there. But that is a way where you bring together all these disparate sources across your organization, some product data, some sales data, all these ETL jobs and to have a centralized view. But that is often used for things like reporting, analysis, now model training, but not really to serve and build applications on top of. And so when I think about that division, it's not about OLTP versus OLAP, because again, a lot of the data that serves modern applications are analytical in nature. It's part of the applications. But I think it's more about do you serve developers or do you serve data teams? And I think that is the type of division that we're seeing and different solutions are going to be done differently. For data teams, they often look for single centralized solutions that are used across the organization because the value there is with centralization. For product teams and for developers, they often have more flexibility that they want the best solution for the application that they're developing. So it could be that time scale is the best solution for a number of those while there are certain applications that even different parts of the organization's building where other databases are perhaps better suited for them as well. Can you share some use cases or users who are relying on time scale solutions? So we actually serve people across a really horizontal set of use cases anywhere from energy to financial and crypto to manufacturing and IoT, transport, logistics, gaming, music, security, observability. And so it's anywhere from the Fortune 500 like HP and Warner and other modern companies like Uber and Coinbase to kind of car companies like Northvolt renewable companies like building car companies like Lucid or renewables like Northvolt building the battery tech for Daimler and everywhere from gaming startups to IoT sensors and everywhere in between. So it's a great combination of major enterprises to the smallest startups. But again, the interesting about modern applications is you could have a 10 person startup dealing with terabytes of data. And so we have people come small companies bring gigabytes and small companies bring tens or hundreds of terabytes all in the interest of serving these type of modern applications. Mike, thank you so much for taking time out today and of course talk about time scale and of course some of the challenges that are there. Thanks for those insights and I would love to chat with you again. Thank you. Thank you for having me.