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

31–40 of 56 posts

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#31

Post by akulkarni »

AdamProut wrote: post #23
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?

This is a reasonable benchmark from the Clickhouse folks for single table anlaytical query performance over smallish data sets (10s of GB of data). Most of the DW vendors are on there. https://benchmark.clickhouse.com/ Timescale apparently lags pretty far behind modern columnstore engines.

(Timescale co-founder)

As with anything, it depends on what you want to do.

If you have an OLAP heavy workload with long scans, etc (which is the type of queries prominent on the ClickHouse page - e.g., Q0 is "SELECT COUNT(*) FROM hits;"), then I would highly recommend systems other than Timescale. (Although we are also working on this ;-) )

But if you have time-series workload, or even, if you love Postgres and are building a time-series and/or analytical application, then I would recommend TimescaleDB.

ClickHouse is great. I just believe in using the right tool for the right job. :-) There are many areas where column store engines beat TimescaleDB. But nothing comes for free - everything has a tradeoff.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#33

Post by djk447 »

avar wrote: post #30
akulkarni wrote: post #19

Earlier quoted context omitted.

(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…

Most people storing time-series are also doing that outside of TimescaleDB. So the relevant question isn't what a typical PostgreSQL user is doing, but whether someone wanting to optimize their storage should look at a PostgreSQL extension, or an upstart database like TimescaleDB.

NB: I work at Timescale.

TimescaleDB is a PostgreSQL extension, just to be clear.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#34

Post by ensignavenger »

akulkarni wrote: post #29
ensignavenger wrote: post #27

Earlier quoted context omitted.

But almost all of your posts and benchmarks are based on the closed source version of Timescale. Everywhere I have seen it is always recommend to use the closed source version to get decent performance out of it.

(Timescale co-founder) Just to clarify: Nothing on Timescale is closed-source. It is all source available, all on Github. Some of it is Apache2 licensed, some of it is Timescale Licensed. And it is all free.

Since the Timescale License is not an open source license, it is a closed source license. You are right, it is source available, but source available is also closed source. It is closed because it is not open. And it might be free as in beer, but it is not free as in freedom.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#35

Post by miohtama »

djk447 wrote: post #28
srcreigh wrote: post #11

> 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 experim…

Disclosure, I work at Timescale. We are kindred spirits I think! I did this too [0] a while back at a previous company and it actually served as part of the inspiration for our compression work! It's fun, but a bit difficult to query at times. Our compressed columns do also get TOASTed and stored out of line. I'm not sure that it's going to be much more efficient than the Timescale format once it's compressed, we hav…

If I am running already compressed filesystem like ZFS with zstd, can I disable TOAST and compressed columns altogether somehow?

https://dba.stackexchange.com/questions/315063/disable-toast...

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#36

Post by djbusby »

akulkarni wrote: post #18
fzliu wrote: post #7

Earlier quoted context omitted.

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:…

Cool. Now do VS PG+extensions like asked about up-thread.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#37

Post by skeletal88 »

ensignavenger wrote: post #34
akulkarni wrote: post #29

Earlier quoted context omitted.

(Timescale co-founder) Just to clarify: Nothing on Timescale is closed-source. It is all source available, all on Github. Some of it is Apache2 licensed, some of it is Timescale Licensed. And it is all free.

Since the Timescale License is not an open source license, it is a closed source license. You are right, it is source available, but source available is also closed source. It is closed because it is not open. And it might be free as in beer, but it is not free as in freedom.

The source code is available, when someone says something is closed source then it usually means that the source code is not publicly available.

Do you want amazing things? Everything can't be "free as in beer" wtf does that even mean, i don't get free beer from anywhere.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#38

Post by didip »

doliveira wrote: post #14
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?

Unfortunately not yet, but I am actively investigating.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#39

Post by doctor_eval »

ensignavenger wrote: post #34
akulkarni wrote: post #29

Earlier quoted context omitted.

(Timescale co-founder) Just to clarify: Nothing on Timescale is closed-source. It is all source available, all on Github. Some of it is Apache2 licensed, some of it is Timescale Licensed. And it is all free.

Since the Timescale License is not an open source license, it is a closed source license. You are right, it is source available, but source available is also closed source. It is closed because it is not open. And it might be free as in beer, but it is not free as in freedom.

My recollection is that the TS license simply has protection against using the TS code to compete with TS, ala Amazon RDS.

While some people on HN feel that this is an impurity they can’t live with, I personally think it’s a small price to pay to enable development of TS to continue. In my opinion, claiming that it’s closed source is somewhat dogmatic. Many open source licenses have some kind of restrictions on use; the GPL comes to mind.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#40

Post by ensignavenger »

skeletal88 wrote: post #37
ensignavenger wrote: post #34

Earlier quoted context omitted.

Since the Timescale License is not an open source license, it is a closed source license. You are right, it is source available, but source available is also closed source. It is closed because it is not open. And it might be free as in beer, but it is not free as in freedom.

The source code is available, when someone says something is closed source then it usually means that the source code is not publicly available. Do you want amazing things? Everything can't be "free as in beer" wtf does that even mean, i don't get free beer from anywhere.

It is a phrase that Richard Stallman created, and well known in free software communities- https://www.wired.com/2006/09/free-as-in-beer/, https://www.gnu.org/philosophy/free-sw.html
Post reply on HN