[hardwaresofton]

Have you written about this anywhere? I'm sure TimescaleDB would love to signal boost that post, and I separately would love to read about how you have it set up and the nitty gritty of the setup.

How are you dealing with backups/WAL and general DB administration? Are you using Timescale Cloud?

[fourseventy]

Not OP but I run a Timescale instance with the same order of magnitude inserts/sec and have been running it for about 2 years now. The database is closing in on 1 TB on disk. We don't use Timescale Cloud, we just host it on a VM in Google cloud with 8 CPU's and 32 gigs of ram, which seems adequate for now. We do WAL backup using the WAL-G tool which backs the db up to google storage.

[hardwaresofton]

Thanks so much for this. 2 years at that insert speed only being about 1TB of data is fantastic.

I've also had many discussions on backups (Barman, backrest, Wal-E/G) etc and always feel like I have to look it up afresh every time to get myself back up to speed on which one I should be using.

[fourseventy]

Ya the backup solutions are complicated. I don't even remember the differences between those different tools. All I remember is that I spent about a day researching the tools and determined that Wal-G was the best one to use for our use case.

[fabioyy]

I have done no optimization, no WAL partition, no slave (yet). i'm just using a single t3a.xlarge Aws instance with 1500 IOPS (EBS Volume).

we use 1500IOPS just to speed up our read-only jobs and reports.

i'm just using AWS EBS snapshot feature ( every hour ) for backup.

[hardwaresofton]

Thanks for going into the nitty gritty, super helpful to know what your setup is like.

In the I’ve had terrible experiences with on-demand IOPS but now I feel like even 1000 provisioned (the least you can get) is too much for the workload I was running… the app was mostly idle but had bursts that would overwhelm