Dynamically Scaling PostgreSQL Databases – Mike Freedman, Timescale

This is Textron tv. Hey guys, thanks for the throw. We're here with Michael Freeman, who is CTO for timescale, and he's gonna be Michael.

I'm gonna be Mike to make things clear for everybody. And we're talking about Postgres and how to dynamically scale these environments 'cause it's been something of a challenge. And well, there's new ways of thinking about this.

Mike, welcome to the show. Thanks for having me. So, explain to us what's going on here, because we have seen the rise of so-called Serverless computing frameworks that dynamically scale, but there are issues and challenges that go with that, and I have to kind of bring in a whole new architecture.

How did you go about skinning this cat without necessarily requiring me to use a serverless computing framework? Yeah, so let's kind of go back and think about where, you know, where serverless really caught on, which is that people were building these applications and they realize that they don't really wanna run servers, they just wanna run little pieces of code in the cloud and it'll scale up. It'll run when you need to, it'll scale down.

And we basically built these multi-tiered architectures that had all these little bits of serverless compute, and that works great. The one thing that most of those serverless frameworks don't handle is state is data. And the reason they scale up and scale down, and in Kubernetes, you spin up nodes and spin them down is because you've basically moved the state problem to something else.

You spin up, you don't need any data. And so you can start processing and you move on. What that other thing, you move the data problem or state problem is often databases.

And so typically the place that databases are on your stack is behind all those serverless functions. And they're the things that are basically available to have your data ready to go whenever those serverless functions kick up and start processing a, a request and need some data to, to further process that request. And so then the question is, well, what is the layer that we want from our database tier?

And, you know, people have explored this differently for a long time, your database ran in the cloud similar to the way it's been running for many years, in that you basically perver provisioned a server. It was a virtual machine, it was always running. 'cause every time that serverless function ran up, you needed it to be there to process it.

And, and some people started saying, well, can we bring this whole idea of serverless also to the database? And the problem is, when you focus on spinning your database up and down, you know when your computer, you know, when you're at home, you boot up your computer, it takes a while for your computer to, to boot up its applications to load memory from disc and everything. And things are slow in the beginning.

And so there are some applications where, you know, actual serverless databases, that means they get a request, they spin up, they process, they spin down, make sense? But it's probably when you are only, you know, handling the really rare, the rare query, very intermission workloads. Um, but in a lot of cases what you actually wanna do is you wanna have the database running, but you also want it to be able to kind of operate within some type of range.

You know, you know, it needs a at least this, but occasionally you want it to, uh, go higher either because workloads are variable or workloads are bursty and you want to be able to go higher when you need it and kind of only charge what you use. And then sometimes that's actually what we've been building at Timescale. We came from an area we build on top of Postgres, which is one of the most popular databases.

We first basically showed how you could specialize Postgres for certain workloads. We started in time series and analytics, but in general, these are examples of workloads that are very demanding. People are building, you know, workloads that actually need real, real data and real compute behind them.

And we started taking this started in time series analytics. We brought that to AI and Vector, and now we're bringing those same technologies to the broader Postgres work Postgres and database ecosystem. And that's what we call dynamic Postgres.

It's, it's good for any type of relational workload, uh, as well as analytics and time series and ai, but it actually allows you to kind of dynamically adapt the amount of resources you have while ensuring you always have at least that what you have to serve production workloads. So it could both, so it could be both performant and cost effective. Is this something that I deploy or is it a service I invoke that you're managing on my behalf?

So Timescale runs a, a managed service. We run our, uh, timescale cloud, a cloud offering. And so you just press a button and there's a database ready for you or, or access one of our Terraform operators or ACLI.

And there is a database, uh, ready to run when you need it. Um, some of our core technology, which is we built initially for time series is open source and people also run it, you know, tens or hundreds of thousands of companies run it worldwide. Um, but this dynamic capabilities that we're really talking about is part of our, our managed offering.

So we could really offer that entire cloud experience and you could basically just focus on building a great application. I feel like a lot of times developers will go out and get something that feels like a document database just because the DBA took too long for them to actually give them access to a relational database. And then I wind up with all these different databases.

'cause eventually they throw it back over the wall when they get tired of managing it. So can we, um, streamline the number of database architectures we have to support if we made relational just more accessible? That's, I think that's a big thing of what we did at at at timescale as well.

If you remember, I started by saying we basically built on top of Postgres. And you know, if you're familiar, Postgres is, I think today is considered the most popular and the most loved database by, uh, developers. It actually has its roots back in the 1990s.

It has been a long journey and over the years it's just gotten better and better and even, and what effectively it did was become a very general purpose engine that you could then build specialization also on top of. And so that's where timescale started by enabling this general purpose database that has a massive ecosystem. People know how to run it, uh, lots of integrations.

It's really battle tested by millions of companies worldwide. And to show that in fact, because we could, it has this extension framework where we could build inside the core and then also build around it with our cloud, we could basically make it work for settings that you otherwise wouldn't think you could do. So we initially made it work for time series and now, and we made it work for analytics so that you bring together both your, uh, you know, traditional transactional workloads as well as those things which are customer facing, but need to serve a lot of, of dashboards and metrics and, and real-time analytics.

Uh, and we made it, we recently, uh, a month or two ago, we re released our special, uh, vector indexing that made it work for a lot of generative AI applications better as well. And so what this all means is that to your point, you don't need to run five databases and that they're isolated. You need to get different training, you need to, um, they're siloed.

You can share data, you could bring all of that into Postgres, and yet we could specialize it enough and supercharge it. So for all these different types of workloads could, could continue to work on Postgres. We kind of say internally that, you know, we basically specialize Postgres for demanding applications, but also you could start with Postgres, scale with Postgres and then stay with Postgres throughout your developer journey.

What becomes of the DBAs in this scenario, if it's a managed service, how does their job evolve? I think we basically see, have been seeing that evolution over the last decade or two as people as broader workloads move to the cloud. You know, just because companies started moving to the cloud doesn't mean that we don't, you know, maybe cis admin turned into DevOps, uh, and the traditional DBA what, what the movement of from an install a database on your own hardware to run and manage services in the cloud doesn't mean that databases aren't a critical part of your software stack.

It just means that you could now actually focus on things where, you know, people could use their ingenuity and expertise to be able to do those more value added things. Figuring out how to better optimize performance, how to, uh, even do better query query tuning if you, when you need it, or focus on helping build builder applications as, as opposed to upgrades and make sure backups are set up and make sure you have your proper, uh, replication, failover strategies, strateg. We can standardize those things and because we do it across fleets of thousands of databases, we could basically harden that a lot more and make it much more automated and, and battle tested than having, you know, one-off, uh, deployments that are run by by individual DBAs.

There is of course, no shortage of chatter these days about all things AI will that get applied to this and what might that look like? Yeah, so we we're really excited by all the work going on in there. A as I mentioned about, uh, two months ago, we, we've been working on this for some time, but we announced, uh, specialized how we further specialized Postgres now to really be super advanced when it comes to supporting, uh, in this case the generative AI applications, all the work around large language models and, and, and those other applications, um, more broadly.

And, and what that means is that now we talked about specialized databases. Now instead of having a separate database for your vector data and a separate database for your documents and your relational linear analytics, you could run that all on top of, of timescale and Postgres. And so, uh, both operationally it's simpler, but it also allows even data sharing.

So we just actually talked last week with partnerships with Lang Chain and, and others, how you could actually even train your language models on top of data sitting inside the database. Again, simplifying your stack and then basically being able to focus on applications. The other thing is, of course, is that a big part of a lot of what these new, uh, AI applications are focusing on is, is part of that is, is is analytical and time series data.

And so a lot of what your, what your training, uh, AI models are, are, are streams of events and collections and observations. And so timescale in some sense has been serving a lot of, uh, AI businesses for some time, although we were basically the source of their data that they were using to build their and serve their models on top of, as opposed to actually what we're doing now, which is also serving those type of, uh, LLM applications as well. Mm-Hmm.

Ultimately, how automated do you think all this might get? 'cause we're gonna apply AI to the actual management of the databases in the infrastructure as we go along as well, right? I think so.

I mean, we're gonna see some of this, um, you know, uh, times can other companies, you know, for a while have, part of our managed services has had automations where it even will do things like, uh, tune your database based on, uh, your resource usage. And so I think the advantage of being a, you know, what we could do also as, uh, providing a managed uh, service is that we have visibility not only over one application, one single database, but we have visibility across entire fleets of thousands or tens of thousands of databases. And what that allows us to do is then basically build that, uh, expertise so that when we build these tools and we could train different models on, uh, in order to help with operations and, and optimize tuning, you know, we could do that with a much broader view than just a, a single database.

Um, you know, in general, I think that there's, you know, we've seen a massive, um, uh, you know, the, the acceleration of AI applications over the last couple years has been really astounding in the last year or two, especially, uh, in the LLM space since Transformers came. Combat has been special. I think the problems mainly for, uh, automated infrastructure is, is a little bit different.

Probably more in the reinforcement learning camp than what has really been the big focus in last year of, of language models. But I think we're just going to see a further acceleration of this. Hmm.

There's been a lot of discussion these days in the open source community over licensing terms and various things that go on. Um, what is your sense of where does the open source community go from here? How do folks kind of make money but still benefit?

Do pe more people need to contribute? What's your sense of where are we in this open source community as it applies to databases? Yeah, this has been a big area for companies like Timescale, which ultimately, um, do a lot of r and d and development around core data infrastructure.

Uh, what timescale, when timescale initially launched, we licensed, uh, the core of, of our, of our offering as Apache two, which is a very permissive open source license. Um, we never relicensed anything, but, uh, approximately in late 2018, we introduced a new license, which is our community license like many other companies did as well. Um, effectively, uh, our, all of our code is, is open and, and on GitHub, um, people could run our software free.

They could, they could modify for their own use. The only thing our license actually prevents is it basically prevents the hyperscalers like Amazon and Google and Azure from basically offering timescale as a service. And I think that's what, that has been the trend with a lot of independent software vendors like Timescale and Confluent and Hasi and, and, uh, elastic, where as the primary monetization in open source, at least for commercial open source companies, uh, move from a support model, which, you know, it was under, let's say Red Hat to a services model, um, you know, which is, it is in the modern cloud.

Um, basically the licensing is, is is a counter to, to really the large, uh, distribution and bundling benefits that the hyperscalers have. So if you basically need to, if people are deployed on Amazon, uh, the fact that not only does obviously Amazon make it easier to use another Amazon service, you buy annual commits. They, in fact, um, it's most people in one cloud don't actually wanna run a database that sits in another infrastructure, both for latency reasons, but also the clouds charge for network traffic outta the cloud.

So there's all these, uh, bundling and distribution benefits that the hyperscalers have done. And I think that's why you see companies like Timescale basically says, look, we want to, um, you know, we're happy to compete, um, but you know, we have to do it kind of on, on on equal terms. And so I think that the way you see s GU is say, Hey, if you wanna embed timescale, you could do it for free.

If you want to put in your own applications, you know, we have major Fortune 100 companies that ship timescale as part of their software. Um, and you know, that's, that's certainly allowed under our, under our community license. Um, you know, we just want to make sure that if something comes for a managed offering, they come to timescale the company.

Right? Folks, you heard it here. If we wanna have nice things, the people who make the nice things have to eat.

So we gotta figure out how to make those payrolls and make the whole system work. Right. There we go.

Hey Michael, thanks for being on the show. Thanks a lot, Mike. All right, back to you guys in the studio.