[HN Gopher] The New Timescale Cloud
___________________________________________________________________
The New Timescale Cloud
Author : neom
Score : 52 points
Date : 2021-10-05 16:23 UTC (6 hours ago)
(HTM) web link (blog.timescale.com)
(TXT) w3m dump (blog.timescale.com)
| [deleted]
| zokier wrote:
| Doesn't AWS Aurora Serverless kinda cover all the main 4 points
| (easy, scalable, familiar, flexible)?
| geuis wrote:
| Can someone boil this boilerplate down into 2-4 meaningful
| sentences?
| errwhat wrote:
| 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
| akulkarni wrote:
| 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.
| LoriP wrote:
| 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...
| aeyes wrote:
| One sentence summary: They are now storing your data on EBS
| instead of local disks.
| errwhat wrote:
| Think they've removed the ability to choose non AWS too.. I
| cant see region selection in docs either. And a price
| increase.
| akulkarni wrote:
| 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.
| errwhat wrote:
| 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?
| maxbaines wrote:
| 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/
| avthar wrote:
| 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...
| akulkarni wrote:
| 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)
| whitepoplar wrote:
| 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!
| ryanbooz wrote:
| [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/...
| [deleted]
| epberry wrote:
| 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.
| gneray wrote:
| 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...?
| clarkbw wrote:
| 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.
| brightball wrote:
| 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.
| tomc1985 wrote:
| You can experiment with a self-hosted version for free,
| indefinitely
| brightball wrote:
| 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.
| tomc1985 wrote:
| 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.
| errwhat wrote:
| Are they giving free egress on the public 5432 endpoint - if
| you host with say DO/Linode (obviously you have DO/Linode
| limits too)?
___________________________________________________________________
(page generated 2021-10-05 23:01 UTC)