Live data from Hacker News

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

timescale.com

21–30 of 102 posts

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

#21
post #12
post #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 a…

In a funny bit of coincidence -- we didn't post this link to HN :) -- we just published a blog post today comparing Timescale vs. native Postgres: https://blog.timescale.com/timescaledb-vs-6a696248104e tl;dr: 20x higher inserts at scale, faster queries, 2000x faster deletes, more time-oriented analytical features

Ok and if one is partitioning by date and dropping partitions instead of deletes in vanilla postgres how does it compare ?

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

#22
post #21
post #12

Earlier quoted context omitted.

In a funny bit of coincidence -- we didn't post this link to HN :) -- we just published a blog post today comparing Timescale vs. native Postgres: https://blog.timescale.com/timescaledb-vs-6a696248104e tl;dr: 20x higher inserts at scale, faster queries, 2000x faster deletes, more time-oriented analytical features

Ok and if one is partitioning by date and dropping partitions instead of deletes in vanilla postgres how does it compare ?

The delete performance will probably be similar, but standard partitions in postgres have a bunch of current limitations.

For example, the insert pipeline is still quite a bit slower, partition creation is still manual, can't do as good constraint exclusion at query time, can't do certain query optimizations we've built in, can't support user-defined triggers, can't handle UPSERTs, doesn't support various constraints, can't do VACUUMing across the hierarchy, etc.

We plan to write a blog post comparing against PG10 partitioning in the future to expand on this a bit.

All this said, we do love Postgres and realize that it's trying to provide a more general-purpose solution, so don't mean this as criticism. We can just build something more targeted at the time-series problem.

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

#23
Could you contrast this with the approaches mentioned in the series of blog posts starting here: https://grisha.org/blog/2015/09/23/storing-time-series-in-po...

That blog post grew to be tgres http://github.com/tgres/tgres https://grisha.org/blog/2017/03/22/tgres-0-dot-10-dot-0b-tim...

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

#26
This looks cool. I love things that get rid of extra dependencies. Influxdb is nice but then I have to support it, get stuff into it and get stuff out of it.

Timescale isn't currently supported by RDS/Aurora though, so it looks like more influx for me wooohooooo!

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

#27
post #19

How would this work together with something like Stolon? https://github.com/sorintlab/stolon

Generally speaking, a TimescaleDB database just looks like Postgres to admin tools. So this looks interesting, and we are already internal Kubernetes users.

Will have to look at more.

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

#28
post #26

This looks cool. I love things that get rid of extra dependencies. Influxdb is nice but then I have to support it, get stuff into it and get stuff out of it. Timescale isn't currently supported by RDS/Aurora though, so it looks like more influx for me wooohooooo!

We've been talking with Amazon, and you can help the process along:

https://github.com/timescale/timescaledb/issues/65

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

#30
post #28
post #26

This looks cool. I love things that get rid of extra dependencies. Influxdb is nice but then I have to support it, get stuff into it and get stuff out of it. Timescale isn't currently supported by RDS/Aurora though, so it looks like more influx for me wooohooooo!

We've been talking with Amazon, and you can help the process along: https://github.com/timescale/timescaledb/issues/65

Nice!!!

Edit: emailed them, hopefully I matter a teensy bit.

Post reply on HN