Scaling Time-Series Workloads on Postgres

Yeah.

So let's talk a little bit about time series, and what are the, like, problem domains and use cases.

Like, if you're someone who's coming from a web background, maybe you've only ever dealt with relational classic-

Yep

...

REST objects and things like that.

Like, what are the types of problems that get you into saying, "Hey, actually, I need a different data structure here.

I need something that looks like a time series?"

People typically do start with Postgres.

So I think sixty percent of the world, you start with a relational database, Postgres being the one that's probably used the most by developers.

But you end up having a particular device or set of devices that are emitting readings, and that could be across a number of different areas as well.

Manufacturing or robotics, medical devices, finance or crypto are also used there, where you have a number of different transactions.

Smart buildings and industrial systems.

So it's a number of different areas, and I think it's a growing area as well, as we look at what we call kind of the physical world, where you have solar energy, any number of things that are all emitting readings on a periodic basis.

And the number of devices within that is growing as well, so you end up with hundreds of thousands or even millions of devices.

We have one customer that has twenty-two million devices, and they're all emitting readings every few seconds, every second, and some even sub-second as well.

So the volume of data that you're ingesting and the volume that's growing over time gets larger and larger, right? And so that challenges the databases in uni- new and unique ways.

The other piece of that is, is that you still need the transactional relational part of the database as well.

And so as you start to grow, and oftentimes people start with Postgres, and you out- as you start to outgrow it, your queries slow down, your ingest slows down.

You have two options really, right? You can separate it off into another solution.

So you bifurcate with some type of analytical database, and then you retain your transactional database.

Or you can adopt a system like timescaleDB that gives you the best of both, where you have co-located in the same system, we can extend it.

And this is with zero application changes at all.

And we can talk about what that migration path looks like, but you're not having to make application changes, where if you bifurcate it, you have to manage multiple data pipelines between this other system.

And typically, most of these systems have some evolution of SQL that is a little bit different, so you end up having to rewrite portions of your application