The New Timescale Cloud | Hacker News Reader

The New Timescale Cloud

blog.timescale.com

62 pointsneom25 comments

Open articleView on HN

Been a timescale user for a little while and here's how this is different than their previous offering:

- Scale compute or storage separately

- One click spin up, pause, and recover

- Configure data retention (docs page not complete)

- Set a refresh policy for continuous aggregates via web console

- One click VPC

There's other stuff in that list but I either didn't miss it in the old Timescale or don't use it. Overall continuing the coupling of dba and analyst/backend dev via software. A nice set of changes.

If anyone from the Timescale team is here, can you give a specific example of how this is different from the "DBaaS" services you reference? I get that you're going to give transparency into what's behind the scenes, which is how it's different from serverless options. But what would be an example of how this "transparent box" is different from something like RDS or Aurora or...?

For the DBaaS services the problem is more of simplicity and developer experience; they are more of a transparent box which can make things more complicated than necessary. You should be able to have a clear paved path for an excellent general database experience with automatic backups, scale, and functionality to improve developer ergonomics. While at the same time, under the hood having this DBaaS like experience which allows you to take more control as needed. Of course it is not easy to offer both simplicity and flexibility, that's a fine line to draw but that is our goal.

I really wish / hope the timescale cloud pricing and features gets somewhere close to the cost of postgres on Digital Ocean https://www.digitalocean.com/pricing/

Timescale employee here. While we do offer plans starting at $24/month [1] on Timescale Cloud, it's worth noting that DO Postgres (and other hosted Postgres solutions) are providing an undifferentiated open-source solution, while on Timescale Cloud you get Postgres underneath (for relational workloads) and TimescaleDB (for time-series workloads), plus other features which provide an enhanced time-series experience (like the explorer dashboard [2], autoscaling, automated upgrades, auto-tuning of configs, just to name a few). So do keep that in mind when comparing prices.

Many users actually find Timescale Cloud to be cheaper because it replaces both a time-series and relational db with a single database that can store (and analyze) both kinds of data.

[1] https://www.timescale.com/cloud [2] https://blog.timescale.com/blog/announcing-explorer-a-better...

Exactly. TimescaleDB is essentially "Postgres++." You get everything Postgres has to offer, plus better performance, scalability, storage consumption (via ~95% compression), etc.

(Also a Timescaler)

For someone who simply wants ultra-scalable Postgres (~2B rows per month ingested) that is only loosely "time series", can you share your thoughts on TimescaleDB vs Citus (w/ newly released columnar functionality)? When should someone choose one over the other? Thanks!

[TimescaleDB DevRel here]

Citus has been a great product and tool for helping to push the scaling story in Postgres and certainly has it's uses.

That said, the three big differences that come to mind initially when talking about time-series data are:

1. Partitioning:

In TimescaleDB, hypertables manage chunks/partitions automatically and lots of other value is built on top of the chunk architecture. Regardless of whether you insert new, forward moving data, or load historical data from 10 years ago, you don't have to ensure the partitions are ready and waiting for you, TimescaleDB takes care of that.

In Citus, partition management is still a manual process (at some level). Version 10.2 does provide some new APIs[1] for creating the underlying partitions, but it's still a "manual" process (that can be automated with work).

2. Time-series specific features

Managing and querying time-series data is more than having partitions across multiple nodes/shards. Because we manage the chunk architecture, we also focus on automated policies that help you manage every aspect of how time-series data works. Continuous Aggregates[2] for intelligent aggregate query refreshes. Compression[3] that achieves 93%+ in many production cases. Data retention[4] that makes it easy to manage how much data you keep, both raw and aggregate data! Built-in user defined actions that doesn't require a separate extension like pg_cron.

All of these features can be automated with policies so that they run without you having to call specific APIs on your own (although you can do that too).

Citus has focused on scaling but can be used more generically for time-series data if you want to do more of the maintenance yourself (again, at this point).

3. Compression I mentioned it above, but one thing TimescaleDB does different compression algorithms for different data types. It's not yet configurable, but it generally provides better performance than what Citus because they use ztsd for all column compression.

Everything else they've announced with columnar compression (hybrid columnar/row data store) has been a TimescaleDB feature since compression was introduced in version 1.5.

HTH!

[1]: https://www.citusdata.com/blog/2021/09/17/citus-10-2-extensi... [2]: https://docs.timescale.com/timescaledb/latest/how-to-guides/... [3]: https://docs.timescale.com/timescaledb/latest/how-to-guides/... [4]: https://docs.timescale.com/timescaledb/latest/how-to-guides/...

This might be where I finally sit down and experiment with Timescale Cloud.

$24 / month is an entry point price that I can use to start a project with at least.

You can experiment with a self-hosted version for free, indefinitely

Biggest issue is that, when I go to production for a small app that's just starting out, I don't want to spend time managing a self hosted version.

It's a postgres install with a proprietary extension. Management burden is about as low as it gets for a small app -- make sure its got HD space for storage and logs, lock it down sensibly, set up a cron job to export daily backup dumps to S3, and you're good.

I one-man-armied software dev for a $20m/yr company doing exactly this a little while back and postgres caused problems pretty much never.

Are they giving free egress on the public 5432 endpoint - if you host with say DO/Linode (obviously you have DO/Linode limits too)?

Doesn't AWS Aurora Serverless kinda cover all the main 4 points (easy, scalable, familiar, flexible)?

Can someone boil this boilerplate down into 2-4 meaningful sentences?

We're still doing hosted iaas on aws/gcp/azure and we're adding some small new features, other than its pay per word blog post by the looks of it. Dont get me wrong I like timescale but this is an unclear blog post. tl;dr how is this different than Managed Service for TimescaleDB - it seems identical in features and all the comparison is against serverless and other DBaSSs - reskimmed it and still no clearer

Thanks for the feedback. What the post is trying to paint is a vision that is different than current DBaaS and "black box" serverless options. Something where you can see and "feel" the database that you are working with (similar to a DBaaS), but where you can still offload the scaling burden (similar to Serverless).

That is what we are calling the "transparent box."

The new Timescale Cloud is designed around this new vision. It does not fully realize it today, but that is what we are working towards.

Hope this helps - and if not, happy to continue the dialogue.

From the author's summary thread:

- DBaaS is Familiar and Flexible

- Serverless data platforms may be scalable and easy but are not so much Familiar and Flexible.

This new Timescale Cloud approach offers :

Easy and Scalable

- Modern cloud architecture, fully decoupled compute & storage

- Autoscaling for worry-free operation

- Autoconfig and autotuning, including whenever resources change

- Easy to get started and scale with need

Familiar and Flexible

- Full SQL

- Built on Postgres (relational db mental model)

- Works w/ all Postgres-compatible tools, connectors, & apps

- Developers can be immediately productive, building on existing skills

So it's addressing those gaps in the current solutions...

One sentence summary: They are now storing your data on EBS instead of local disks.

Think they've removed the ability to choose non AWS too.. I cant see region selection in docs either. And a price increase.

Region selection coming soon. Price should be cheaper for most configurations. Also, offers decoupled storage / compute, so is more cost effective than needing to resize both at the same time. But let me know if you are seeing differently.

Its difficult to break out what parts of the site are talking about cloudv1 and cloudv2, Ill wait until site all sorted... Im sure im looking at managed service for timescaledb still named cloud on most of the site. GCP/Azure is gone for cloudv2?

Managed Service for TimescaleDB (MST) and the new Timescale Cloud are just two different products. (Not v1 vs v2.)

They are both in active use and development. Different users will prefer one over the other.

We could do a better job describing the differences on our website - noted (thanks!)

GCP/Azure are still supported on MST.

So there are now 3 hosted offerings? Forge, v1 and v2?

This is getting extremely confusing.

2 hosted offerings.

From the blog post:

  (Some of you may remember that we launched the first “Timescale Cloud” 2.5 years ago, as the world’s first fully-managed time-series database-as-a-service on AWS, GCP, Azure. That product is alive and well, and fully supported as before, but is now called “Managed Service for TimescaleDB”.)

  Today we are announcing the new Timescale Cloud (formerly known as “Timescale Forge”), a database cloud for relational and time-series workloads, built on PostgreSQL, and architected around this vision of the “transparent box”.

Reply on news.ycombinator.com