Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TimescaleDB 2.7 vs. PostgreSQL 14

timescale.com

Post reply on HN
Print view View original

11–20 of 56 posts

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#11

Post by srcreigh »

> For example, one recent query planner improvement excludes data more efficiently for relative now()-based queries (e.g., WHERE time >= now()-’1 week’::interval).

This could be done by just calculating the start date in code too.

> When hypertables are compressed the amount of data that queries need to read is reduced, leading to dramatic increases in performance of 1000x or more.

At my workplace we recently experimented with storing time series data in an array in a postgres row. This gets compressed as a TOAST array, can store thousands of ints in just a few DB pages (aka loading it is about the same as an index scan). We also use Timescale for a different service mind you. I'm sure this format is more efficient than the Timescale format too. In Timescale you would need rows containing (for example) (date, user_id, time_on_site), one row per day. The postgres array format (start_date, user_id, time_on_site_by_date) indexing where 0=start_date, 1=start_date+1 is like 1/3rd the size uncompressed. And yea, even if something is compressed, you still gotta put the uncompressed version in memory somewhere.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#12

Post by g8oz »

chrisco255 wrote: post #3

Should be noted that article is titled Timescale + Postgres vs. Postgres alone. Timescale is built on Postgres so it's not really a competition per se.

Right, the "vs" gives a much different and frankly misleading impression of the article than the "+".

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#14

Post by doliveira »

didip wrote: post #2

What about TimescaleDB vs a lot of other OLAP databases like ClickHouse, Druid, Pinot, Databend, etc.? Or hybrid databases like StarRocks or TiDB?

As a sidenote, Databend's elevator pitch sounds quite good: from what I've seen there's quite a lot of complexity in managing co-located storage and compute like ClickHouse, Druid and Pinot. Leveraging object storage instead seems like a good alternative.

Do you have some experience with it?

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#15

Post by tda »

krn wrote: post #6

If integration with PostgreSQL is not a requirement, I would suggest looking at QuestDB[1] for the best performing open-source timeseries database currently on the market. [1] https://questdb.io/blog/2021/07/05/comparing-questdb-timesca...

Are you sure it is the best performing? The article only compares to influx and timescale, which are very far from the fastest timeseries databases out there. How does it compare to clickhouse? I found this https://questdb.io/blog/2022/05/26/query-benchmark-questdb-v..., but the numbers are so far off (and clickhouse is much slower than timescale in their examples) that I kind of struggle to believe them.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#17

Post by ebiester »

fzliu wrote: post #7
boomskats wrote: post #5

Whenever I see these posts from TimescaleDB, I always want to ask them how it compares in performance to alternative extensions that implement the same features, rather than just comparing TimescaleDB to vanilla PostgreSQL. For example, they mention their automated data retention and how it's achieved with one SQL command, and how DELETEing records is a very costly operation, and how "even if you were using Postgres…

Seconded. I understand that Timescale extends Postgres, but I'd still like to see performance comparisons relative to other time-series databases such as InfluxDB or even TiDB. Shameless self-plug: we're also building database technology, but for embedding vectors ( https://milvus.io ) rather than time-series data - when doing query performance comparisons, we get several orders of magnitude of performance improvemen…

I think it's fair to mention it, but with the specific caveat of "If your workload has these characteristics, we are a particularly good fit."

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#18

Post by akulkarni »

fzliu wrote: post #7
boomskats wrote: post #5

Whenever I see these posts from TimescaleDB, I always want to ask them how it compares in performance to alternative extensions that implement the same features, rather than just comparing TimescaleDB to vanilla PostgreSQL. For example, they mention their automated data retention and how it's achieved with one SQL command, and how DELETEing records is a very costly operation, and how "even if you were using Postgres…

Seconded. I understand that Timescale extends Postgres, but I'd still like to see performance comparisons relative to other time-series databases such as InfluxDB or even TiDB. Shameless self-plug: we're also building database technology, but for embedding vectors ( https://milvus.io ) rather than time-series data - when doing query performance comparisons, we get several orders of magnitude of performance improvemen…

[Timescale co-founder]

We have published many, many benchmarks versus other database systems. IIRC all of them also made the front page of HackerNews.

Here are some of them, for your reading pleasure :-)

TimescaleDB vs. InfluxDB: https://www.timescale.com/blog/timescaledb-vs-influxdb-for-t...

TimescaleDB vs. ClickHouse: https://www.timescale.com/blog/what-is-clickhouse-how-does-i...

TimescaleDB vs. Timestream: https://www.timescale.com/blog/timescaledb-vs-amazon-timestr...

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#19

Post by akulkarni »

boomskats wrote: post #5

Whenever I see these posts from TimescaleDB, I always want to ask them how it compares in performance to alternative extensions that implement the same features, rather than just comparing TimescaleDB to vanilla PostgreSQL. For example, they mention their automated data retention and how it's achieved with one SQL command, and how DELETEing records is a very costly operation, and how "even if you were using Postgres…

(Timescale co-founder)

That's a fair question.

We find that most developers storing time-series data on Postgres are doing so without pg_partman. So we first wanted to provide a benchmark that would be useful to most developers.

This benchmark was also the result of months of dedicated work. So the team did spend a lot of time on this. Unfortunately, they ran out of time to cover pg_partman. But that comparison is on our list of things to do soon.

Thanks!

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#20

Post by akulkarni »

chrisco255 wrote: post #3

Should be noted that article is titled Timescale + Postgres vs. Postgres alone. Timescale is built on Postgres so it's not really a competition per se.

(Timescale co-founder)

Yes, 100%. We deliberately choose the "+" symbol instead of "vs." for this blog title. We love PostgreSQL. :-)

Post reply on HN