3 ms·

i'm using timescale to store sensor/gps log ( 50 inserts/s - 24/7 ). after 2 months still very good )

hardwaresofton 5y ago
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?
- fabioyy 5y ago
  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 5y ago
    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
- fourseventy 5y ago
  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 5y ago
    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 5y ago
      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.

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?

fabioyy 5y ago
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 5y ago
  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
fourseventy 5y ago
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 5y ago
  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 5y ago
    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.