
Timescale Cloud: Multi-cloud, fully-managed time-series in AWS, Azure, and GCP - bithavoc
https://blog.timescale.com/blog/fully-managed-time-series-data-service-now-available-in-aws-azure-gcp-75-regions-compare-vs-influxdb-timestream/
======
eloff
TimescaleDB is great, not just for timeseries data, but also if you're trying
to scale your Postgres database (with some cavaets, obviously.)

One often has a small number of tables, often a single table, with a high
write workload. Changing it to a timescale hypertable, provided you can work
with the additional restrictions that has, can let you instantly 10X your
write throughput (or more with multi-node timescale.) That's a lot cheaper
than trying to scale your database write IO by 10x.

I like multi-cloud services like this because it reduces the vendor lock-in
that happens with these public clouds.

~~~
ants_a
Why wouldn't you use built in partitioning for this?

~~~
mulmen
I think its a time/money tradeoff. I recall a comment along those lines
(paraphrased) the last time I asked about TimeseriesDB. It's the fundamental
calculation of SaaS/Cloud.

~~~
ants_a
I don't feel there is a significant time investment with using the builtin
way.

Timescale has some neat features for handling time series data, but for just
sharding out data for scalability I can't see it offering anything
substantial. And in that vein, I feel the marketing is somewhat disingenuous
in the performance claims. When comparing to vanilla PostgreSQL it is
comparing against a very naive usage pattern. People have been getting the
same kinds of performance increases from partitioning out time series data for
a loooong time.

~~~
akulkarni
The advantage on inserts with TimescaleDB is the automation. The built-in way
on Postgres still requires a lot of manual maintenance, especially as data
patterns change. TimescaleDB adjusts automatically.

(Nothing against Postgres - it just that Postgres needs to design for the
general use case, while we can optimize for time-series.)

But TimescaleDB is much more than automatic partitioning. You also get:

* 15x native compression (95%+ storage savings) [0]

* Faster queries for time-series (b/c of our optimizations at the query planning / execution level)

* Automatic data retention policies (for automatically deleting old data) [1]

* Continuous aggregates (real-time materialized views automatically refreshed) [2]

(and lots more)

Happy to answer any more questions!

[0] [https://docs.timescale.com/latest/using-
timescaledb/compress...](https://docs.timescale.com/latest/using-
timescaledb/compression)

[1] [https://docs.timescale.com/latest/using-timescaledb/data-
ret...](https://docs.timescale.com/latest/using-timescaledb/data-retention)

[2] [https://docs.timescale.com/latest/using-
timescaledb/continuo...](https://docs.timescale.com/latest/using-
timescaledb/continuous-aggregates)

~~~
sa46
> 15x native compression

That is a rather remarkable compression ratio. Do you have a link to technical
details? The lightweight compression outlined in the Gorilla TSDB and
implemented in Uber's m3db is 11x which I thought was best in class:
[https://cs.brown.edu/courses/csci2270/papers/gorilla.pdf](https://cs.brown.edu/courses/csci2270/papers/gorilla.pdf)

~~~
mfreed
Yep, absolutely.

Here's a blog post outlining our general approach, which applies type-specific
compression based on a column's datatype. (While m3db only supports floats,
TimescaleDB supports a whole range of 40+ data types.)

[https://blog.timescale.com/blog/building-columnar-
compressio...](https://blog.timescale.com/blog/building-columnar-compression-
in-a-row-oriented-database/)

For example, by default we employ:

\- Gorilla for floats (+ some optimizations for faster decoding)

\- Delta-of-delta + Simple-8b with run-length encoding compression for
timestamps and other integer-like types

\- Whole-row dictionary compression for columns with a few repeating values (+
LZ compression on top)

\- LZ-based array compression for all other types

And the architecture is extensible to support new/updated compression
algorithms for different data types. The above are all lossless algorithms;
obviously one could drop precision to achieve higher rates.

We also wrote a post describing these various approaches in a bit more detail
for folks interested in learning (although a summary compared to the Facebook
paper): [https://blog.timescale.com/blog/time-series-compression-
algo...](https://blog.timescale.com/blog/time-series-compression-algorithms-
explained/)

Obviously, your compression rate depends heavily on workload, but the number
15x comes from _median_ performance that users see in the field against their
real databases, not just a synthetic or single workload.

------
mfreed
And...if anybody is interested in helping us build the best cloud service for
time-series data, we're hiring cloud engineers!

[https://www.timescale.com/careers/4128985002-cloud-
engineer](https://www.timescale.com/careers/4128985002-cloud-engineer)

Timescale is a remote-first company with amazing folks all over the world.

We're also actively looking for technical support engineers with strong
Postgres backgrounds: [https://www.timescale.com/careers/4615287002-technical-
suppo...](https://www.timescale.com/careers/4615287002-technical-support-
engineer)

------
brightball
I would love to see something like this with pricing that also competed on the
lower end with various RDS and Cloud SQL offerings.

Just using Timescale instead of RDS or Cloud SQL PostgreSQL would be a virtual
assumption, but with the starting price points so much higher it makes the
decision to START with Timescale a lot harder.

~~~
allset_
Agreed. Having your lowest tier offering priced at over $500/mo is cost
prohibitive in a lot of situations. Even their "dev" tier is $130/mo for a
single instance. It would be much nicer if they just let you choose how much
storage, CPU, and memory you need rather than only letting you select from a
limited set of offerings.

~~~
mfreed
The main difference on Timescale Cloud between dev (starting $115) and
production is just the resource availability and slightly longer PITR recovery
period for non-dev options. Both offer same full TimescaleDB experience,
console, ability to upgrade/downgrade, fork your database, etc.

If you do want a lower priced option, we actually recently also released a
second managed cloud offering in public preview, Timescale Forge:
[https://timescale.com/forge](https://timescale.com/forge).

Timescale Cloud provides great flexibility with multi-cloud and 75+ regions,
security conscious options like VPC peering and SOC2/ISO/HIPAA compliance, and
a more traditional DBaaS Experience.

Timescale Forge is a innovative platform with capabilities like decoupled
compute and storage (so you can select yourself the exact configuration you
want, starting at $49/month), instant pause/resume, native support for our
Prometheus integration, and more coming...

~~~
dkersten
Eek, Forge price starts at $49 but the next tier up is $166, after which it
incrementally increases. That’s quite a jump. If my budget is in that price
range, then such a jump is likely a huge deal for me.

~~~
akulkarni
Thanks for the feedback. I'm curious - what kind of pricing would you expect?
Also, is this for an R&D workload, or for something that's already in
production?

~~~
dkersten
Just something that scales more smoothly. The price difference between the
lowest (by price) and next lowest is $117, but the difference between that and
the third lowest is only $19. I know that the difference isn't the same (more
CPU and RAM, vs only more disk space), but it just seems like a big jump.

I could very much imagine that I might outgrow the $49 option, but not to the
point where I'm willing to pay triple that amount.

I'm not necessarily saying you should change it, maybe its just messaging and
targetting. I guess on HN you just get a load of us who are interested in
using it for smaller projects (where the 49 option might be perfectly fine, of
course).

~~~
akulkarni
Appreciate the feedback - thank you!

~~~
dkersten
You're welcome. I've played with the OSS version of TimescaleDB in the past
and am a big fan. Keep up the good work. Perhaps in time, I'll be in a
position to use it more seriously.

------
crb
I see Timescale Helm charts for Kubernetes:
[https://github.com/timescale/timescaledb-
kubernetes](https://github.com/timescale/timescaledb-kubernetes). Are you
using Kubernetes to host the managed service?

~~~
jjjensen90
I brought Timescale to my current job, and I have to plug their Helm charts.
They have made deployment, backup, scaling, and config so easy on k8s for
Timescale. Probably the best postgres chart that exists, period. Great work
TSDB team.

------
aeyes
> 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

~~~
claytonjy
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
oops, a third of a _billion_, not million

~~~
akulkarni
I was wondering about that ;)

------
vladaionescu
We've used Timescale at ShiftLeft since before 1.0. Recommend 100%

~~~
akulkarni
Thank you Vlad for the kind words :-)

------
simonebrunozzi
You have one of the smartest and nicest head of Marketing there. I worked with
Prashant at AWS (more than 10 years ago!) and have the fondest memories.

Besides this: congrats on the launch. I tried your product a while ago and was
impressed. Big cloud providers are the obvious perfect channel for you. Just
get ready for some nasty competition from the same guys :)

~~~
akulkarni
Aw, I agree! Will let Prashant know.

Re: Cloud providers - I also agree, it's a complicated world ;)

------
spo81rty
I was interested in Timescaledb recently but found the cost to be extremely
expensive and you can only get all the good features in their cloud version as
PaaS.

I would also suggest looking at Citus for scaling Postgresql. With the Azure
reserved discounts, Citus is like less than half the price of Timescaledb.
Citus also helps tremendously with multi-tenant scenarios.

Of course, depends on what you are trying to do.

~~~
drpebcak
I’m curious what you mean by this - the community version has most of the
features in it.. and if you are willing to pay for something, you’d an run the
enterprise version on-prem.. my experience with that is that it’s quite cheap,
and you get support as well.

Timescale also has a multi node version now that distributes your data across
a cluster sort of like Citus.

~~~
spo81rty
I want a hosted PaaS solution. I don't want to self host it. That is the
pricing I am comparing.

~~~
akulkarni
Citus and Timescale are apples and oranges.

Citus is just scale-out Postgres. TimescaleDB is Postgres for time-series.

There are a long list of capabilities that we've built for time-series that
Citus does not have: native 15x compression, data retention policies,
continuous aggregates (real-time materialized views refreshed automatically),
interpolation, etc.

Nothing against Citus (we are friends with that team) - but they are designed
to solve a different problem than we are.

------
nodesocket
I am currently using MongoDB to store Ethereum tick price data. I'd like to
switch to Timescale, but wondering if there is a supported Node.js API client?

EDIT: Looks like the documentation recommends using Sequelize ORM.

~~~
mfreed
ORMs that work for Postgres should "just work" for TimescaleDB. So while we
mention Sequelize in some tutorials, if you have a favorite Node.js API
client, you should just go for it.

As aside, you mention enjoy this developer Q&A that a community member
published a few days ago that talk about his experience using TimescaleDB to
build a crypto trading bot.

[https://blog.timescale.com/blog/how-i-power-a-successful-
cry...](https://blog.timescale.com/blog/how-i-power-a-successful-crypto-
trading-bot-with-timescaledb/)

Also, an earlier tutorial:

[https://blog.timescale.com/blog/analyzing-bitcoin-
ethereum-a...](https://blog.timescale.com/blog/analyzing-bitcoin-ethereum-
and-4100-other-cryptocurrencies-using-postgresql-and-timescaledb/)

------
GordonS
Does this come pre-configured for high availability (e.g. replication to a
standby node)? Given the pricing I would have assumed "yes", but I don't see
any mention of it in the blog post?

~~~
GordonS
I meant to ask about backup with point-in-time restore too - is that provided
out of the box?

~~~
mfreed
Yes, there are a number of great options here provided out-of-box:

1\. All plans (including the lowest-cost dev tier) includes PITR recovery out
of the box. You can also "fork" any current database to a second instance
(e.g., for dev & test), also at any recent point-in-time.

2\. Once you create any instance, you can later create a "read replica" with
one click, which creates an asynchronous replica of your primary (e.g., for
ad-hoc queries to not interfere with the primary, or to just load-balance
reads).

3\. On the HA side, our "pro" plans includes automatic synchronous replication
between primary/replica, so that any primary crashes failover without downtime
to the replica. You also get DNS-named endpoints for replicas, again for load
balancing reads.

~~~
GordonS
On the Basic tier, I presume you have to pay for those read-only replicas? Can
they be used for automatic failover, or only for scaling reads?

I don't know what VM SKUs you use on Azure, but at a glance it looks like your
solution would cost 300-400% the cost of the VM, just for your Basic tier.

As a fan of TimescaleDB, I really _want_ to like this, but I'm just not seeing
enough value-add for the price. Maybe I'm missing something, please sell me on
the benefits over managing VMs myself?

------
mfreed
Would love to hear from the HN community: what are some of your favorite
features in managed database or infra platforms, or what do you wish more
platforms offered that are still hard-to-find?

------
k_bx
I wonder, could GNU/Linux change its license (in a substantial way) that would
allow it to get revenue from Amazon for deployments like AWS, similar to how
it was done by Timescale? Would seem fare to get a good chunk of revenue to
Linux development.

p.s.: could Postgres change its license to make Timescale share their revenue?
:D

~~~
xiamx
Why would they do that. These guys are generating revenue by offering managed
service, not by selling opensource software.

~~~
stingraycharles
For the same reasons MongoDB and Redis changed their licenses to avoid AWS et
al offering it as a managed service?

~~~
xiamx
That's a different story. Aws was competiting for revenue with the developers
of MongoDB and Redis' for profit company. Postgres' publisher does not use
managed service as a source of income.

~~~
stingraycharles
Of course, but I was just offering a reason for why they would want to do
that. It’s not as if it’s unreasonable if they did that.

