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.
(Timescale person) This is also true for Timescale Cloud -- especially once people are using it for TimescaleDB (which, as you probably know, is implemented as a low-level extension to Postgres), we see some users start to migrate over their more traditional Postgres workloads to Timescale Cloud as well.
One database platform for all their data, one (great) support team to speak with, etc.
If you want to drop data after a retention period, TimescaleDB is also great here. If you're going to delete millions of rows from a standard Postgres table, it can take a long time and require a lengthy vacuum to recover space - with TimescaleDB it's almost instant, since behind the scenes it is simply deleting the files (chunks) that fall within the time range.
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.
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.
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.
Timescale Forge, which I mentioned elsewhere, is based all around Kubernetes (including StatefulSets), which enables its decoupled compute/storage and instant pause/resume.
For that we employ helm charts, but also have additionally built k8s operators + more internally to handle the dynamic operation and reconfiguration you want from an "full lifecycle"-managed database service, while the helm charts are slightly more static.
> 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 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
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.
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.)
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.
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 :)
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.
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.
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.
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.
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?
I'm curious when folks say they expect a dev plan offering at a pretty low price point to come out of the box with HA - are they comparing this to an Oracle High Availability solution?
Because $75 or $150 for HA on oracle is not going to happen - period.
It's just interesting how the price points are so wildly divergent.
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?
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
With AGPL, if you block AWS, you also block other users unless you have additional licenses for your software, like Mongo and Timescale have to do, and I'm not sure people would want to deal with that when free alternatives like MySQL exist.
With Amazon, they were able to make their own Linux flavor so they could pay Red Hat less. I think if Linux itself sold enterprise licenses, we'd end up with a much more fragmented or corporate batch of OSes taking its place, and I think that's very negative for the ecosystem in general. No one wants to deal with that :/
I'm surprised people want to deal with MongoDB at this point.
[+] [-] eloff|5 years ago|reply
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.
[+] [-] mfreed|5 years ago|reply
One database platform for all their data, one (great) support team to speak with, etc.
And thanks for the compliment!
[+] [-] GordonS|5 years ago|reply
[+] [-] ants_a|5 years ago|reply
[+] [-] mfreed|5 years ago|reply
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...
[+] [-] brightball|5 years ago|reply
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_|5 years ago|reply
[+] [-] crb|5 years ago|reply
[+] [-] jjjensen90|5 years ago|reply
[+] [-] mfreed|5 years ago|reply
Timescale Forge, which I mentioned elsewhere, is based all around Kubernetes (including StatefulSets), which enables its decoupled compute/storage and instant pause/resume.
For that we employ helm charts, but also have additionally built k8s operators + more internally to handle the dynamic operation and reconfiguration you want from an "full lifecycle"-managed database service, while the helm charts are slightly more static.
[+] [-] aeyes|5 years ago|reply
What does that mean? The pricing calculator on 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
[+] [-] fourseventy|5 years ago|reply
[+] [-] mfreed|5 years ago|reply
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.)
[+] [-] claytonjy|5 years ago|reply
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.
[+] [-] vladaionescu|5 years ago|reply
[+] [-] akulkarni|5 years ago|reply
[+] [-] simonebrunozzi|5 years ago|reply
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|5 years ago|reply
Re: Cloud providers - I also agree, it's a complicated world ;)
[+] [-] spo81rty|5 years ago|reply
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|5 years ago|reply
Timescale also has a multi node version now that distributes your data across a cluster sort of like Citus.
[+] [-] nodesocket|5 years ago|reply
EDIT: Looks like the documentation recommends using Sequelize ORM.
[+] [-] mfreed|5 years ago|reply
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...
Also, an earlier tutorial:
https://blog.timescale.com/blog/analyzing-bitcoin-ethereum-a...
[+] [-] mfreed|5 years ago|reply
I'm mike there - come say hi.
[+] [-] GordonS|5 years ago|reply
[+] [-] GordonS|5 years ago|reply
[+] [-] temp667|5 years ago|reply
Because $75 or $150 for HA on oracle is not going to happen - period.
It's just interesting how the price points are so wildly divergent.
[+] [-] mfreed|5 years ago|reply
[+] [-] k_bx|5 years ago|reply
p.s.: could Postgres change its license to make Timescale share their revenue? :D
[+] [-] DetroitThrow|5 years ago|reply
With Amazon, they were able to make their own Linux flavor so they could pay Red Hat less. I think if Linux itself sold enterprise licenses, we'd end up with a much more fragmented or corporate batch of OSes taking its place, and I think that's very negative for the ecosystem in general. No one wants to deal with that :/
I'm surprised people want to deal with MongoDB at this point.
[+] [-] xiamx|5 years ago|reply
[+] [-] dekhn|5 years ago|reply