Live data from Hacker News

Timescale, an open-source time-series SQL database for PostgreSQL

timescale.com

1–10 of 102 posts

Re: Timescale, an open-source time-series SQL database for PostgreSQL

#3
Great to see what you all are doing.

Are there any plans to move timescale to be an extension as opposed to a fork? We've found ourselves at Citus that maintaining an extension lets us more easily stay up to date with current releases. Would love to see the same applied to timescale.

Edit: Looks like it is already one, just was unclear in the docs on the setup steps to me. Well done all.

Re: Timescale, an open-source time-series SQL database for PostgreSQL

#4

Great to see what you all are doing. Are there any plans to move timescale to be an extension as opposed to a fork? We've found ourselves at Citus that maintaining an extension lets us more easily stay up to date with current releases. Would love to see the same applied to timescale. Edit: Looks like it is already one, just was unclear in the docs on the setup steps to me. Well done all.

It looks like it is indeed an extension: http://docs.timescale.com/getting-started/installation?OS=li...

Re: Timescale, an open-source time-series SQL database for PostgreSQL

#5

Great to see what you all are doing. Are there any plans to move timescale to be an extension as opposed to a fork? We've found ourselves at Citus that maintaining an extension lets us more easily stay up to date with current releases. Would love to see the same applied to timescale. Edit: Looks like it is already one, just was unclear in the docs on the setup steps to me. Well done all.

Hi Craig, Timescale person here.

noir-york is correct. TimescaleDB was always an extension, never a fork. So all installations are just a `CREATE EXTENSION` and upgrades between versions just via `ALTER EXTENSION` commands.

But you're absolutely right -- way better than doing a fork!

(Say hello to Ozgun for us.)

Re: Timescale, an open-source time-series SQL database for PostgreSQL

#6
post #5

Great to see what you all are doing. Are there any plans to move timescale to be an extension as opposed to a fork? We've found ourselves at Citus that maintaining an extension lets us more easily stay up to date with current releases. Would love to see the same applied to timescale. Edit: Looks like it is already one, just was unclear in the docs on the setup steps to me. Well done all.

Hi Craig, Timescale person here. noir-york is correct. TimescaleDB was always an extension, never a fork. So all installations are just a `CREATE EXTENSION` and upgrades between versions just via `ALTER EXTENSION` commands. But you're absolutely right -- way better than doing a fork! (Say hello to Ozgun for us.)

[deleted]

Re: Timescale, an open-source time-series SQL database for PostgreSQL

#7
post #2

This is something i've been meaning to look into for a personal project that has a lot of time series data. It'll be interesting to see what they eventually come up with to make time series data not take quite as much space.

Hi Tostino, please let us know how things work.

Regarding compression: While we haven't yet built in any native compression, we regularly run on ZFS and typically get 3-4x compression using that. (Plus with ZFS, insert rates are actually a bit faster, at least when using a single disk (often 25%). It's definitely something to consider.)

Another thing to consider is that Timescale supports easy data retention policies, which can also vary by hypertable (i.e., keep raw data for 1 month, aggregated data for 1 year).

It also supports many disks per server, either via RAID or through Postgres' tablespace. But now you can have multiple tablespaces in a single "hypertable", rather than just one like normal. So especially in cloud settings, it's pretty easy to just add more and more disks to even a single machine.

Re: Timescale, an open-source time-series SQL database for PostgreSQL

#9
A project I work on has time series stats in postgres--it's essentially an interval, a period, a number of fields that make up the key, and the value. There's a compound index that includes most of the fields except for the value. It works surprisingly well, for tens of thousands of upserts per second on a single postgres instance. Easy app integration and joins are a huge plus. I'm really curious to check this out and see how it performs in comparison.
Post reply on HN