3 ms·

> You can now incrementally scale up or down in the region of your choice, with CPU options ranging from 2 to 72 CPUs and storage ranging from 20GB to 10TB Wha

by aeyes 6y ago

> You can now incrementally scale up or down in the region of your choice, with CPU options ranging from 2 to 72 CPUs and storage ranging from 20GB to 10TB What does that mean? The pricing calculator on https://www.timescale.com/cloud https://www.timescale.com/cloud still has the same predefined storage configurations. Also, you might want to remove this customer opinion from the post, standard Postgres won't break a sweat at 100M rows: > We have over 100 million rows of data in development and production, and we needed a database that could handle this volume

mfreed 6y ago
In the Timescale Cloud portal, once you create a database, it's one-click "upgrade" to move between any of these configurations, and it happens with ~zero downtime. That's also true for multi-cloud migration, you just select that you want to migrate from a 100GB instance on AWS to a 200GB instance on GCP, and the migration happens behind the scenes. (Technically, it does so by spinning up a replica of the new configuration / location, and continuously migrates the database, including any online changes happening concurrently. Then, at the last minute, it "swaps" over control from the primary to replica, and then retires the old primary. This is all hidden behind DNS too.)
fourseventy 6y ago
Depends what you are doing with those 100M rows. We have a database with about that many rows and we need to do sums of a few hundred thousand rows, as well as bucket those rows into daily buckets and graph them in real time. With just regular Postgres these operations are pretty slow (> ~5 seconds), but with Timescale continuous aggregates and hypertables they run in milliseconds.
claytonjy 6y ago
That's my quote :) In hindsight I should have said "hundreds of millions"; we're at about a third of a million _sensor packets_ in production, some of which are dozens of rows across several tables. Yeah, you could absolutely stick this in a vanilla postgres instance, but as a sibling post said, you wouldn't get the same performance on the queries we care most about.
- claytonjy 6y ago
  oops, a third of a _billion_, not million
  - akulkarni 6y ago
    I was wondering about that ;)

by aeyes 6y ago

mfreed 6y ago

In the Timescale Cloud portal, once you create a database, it's one-click "upgrade" to move between any of these configurations, and it happens with ~zero downtime. That's also true for multi-cloud migration, you just select that you want to migrate from a 100GB instance on AWS to a 200GB instance on GCP, and the migration happens behind the scenes. (Technically, it does so by spinning up a replica of the new configuration / location, and continuously migrates the database, including any online changes happening concurrently. Then, at the last minute, it "swaps" over control from the primary to replica, and then retires the old primary. This is all hidden behind DNS too.)

fourseventy 6y ago

Depends what you are doing with those 100M rows. We have a database with about that many rows and we need to do sums of a few hundred thousand rows, as well as bucket those rows into daily buckets and graph them in real time. With just regular Postgres these operations are pretty slow (> ~5 seconds), but with Timescale continuous aggregates and hypertables they run in milliseconds.

claytonjy 6y ago

That's my quote :) In hindsight I should have said "hundreds of millions"; we're at about a third of a million _sensor packets_ in production, some of which are dozens of rows across several tables. Yeah, you could absolutely stick this in a vanilla postgres instance, but as a sibling post said, you wouldn't get the same performance on the queries we care most about.

claytonjy 6y ago
oops, a third of a _billion_, not million
- akulkarni 6y ago
  I was wondering about that ;)