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

41–50 of 56 posts

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#41

Post by teraflop »

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.

"Open source" and "closed source" are not the only options. There are plenty of products out there where you're technically allowed to look at the source code, but very restricted in how you can legally use it. The "open" in "open source" is generally understood to mean that users have permission to use, modify and redistribute the software. (Without that permission, calling it "freeware", "shared source" or "source available" would be more accurate.)

That's what "free as in beer" means -- it's a well-established phrase meaning "zero monetary cost": https://en.wikipedia.org/wiki/Gratis_versus_libre

In the case of the non-Apache-licensed version of TimescaleDB, you're allowed to use the software without payment, and you can distribute unmodified copies. But you're essentially forbidden from letting users define their own schemas, or from modifying it or reusing components unless your modified version imposes that same restriction. (The exception is if you agree to transfer ownership of your changes back to Timescale.)

Nobody's saying that Timescale can't build a non-open-source database, only that they should be clear about which parts are actually open. In my opinion, describing it on the homepage as an "open-source relational database" and then promoting it by benchmarking the proprietary version is at least a little bit misleading.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#42

Post by bbirk »

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…

Sometimes when benchmarks are posted on HN that compares your own product (A) with a competitor's product (B), someone working for the competitor refutes the claims made in the blog and states that B were not given the same requirements as A. This particular thread comes to mind [1]. Maybe this is due to the blog writers misunderstanding B or maybe the competitor misunderstands A, or maybe there is a better way to do what was benchmarked using B. I think a better way would be to use some standard benchmark, and publish the code used for benchmarking them.

[1] https://news.ycombinator.com/item?id=31767858

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#43

Post by nextaccountic »

Hey, about the column-wide data compression thing. If I have a column with strings that are highly similar to each other (maybe they are urls, maybe they are HTML documents that were scraped from the same site, but they are expected to contain redundancies)

What's the best approach to get excellent compression? Can I exploit this redundancy within the column somehow? I don't even know the right search terms for this.

TimescaleDB compression will work only for integer columns, right? And in any case, this is not a time series.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#44

Post by didip »

akulkarni wrote: post #31
AdamProut wrote: post #23

Earlier quoted context omitted.

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…

Genuinely curious, aren't a lot of time-series workloads OLAP oriented?

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#45

Post by krn »

tda wrote: post #15
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.

Clickhouse is a data warehouse, not a timeseries database. Timeseries databases are designed with different bottlenecks in the mind:

https://questdb.io/blog/2020/11/26/why-timeseries-data/

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#47

Post by jamesgresql »

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…

Hello! I run Developer Advocacy at Timescale.

Easy fix - we can do a benchmark comparing TimescaleDB to pg_partman.

Longer reply: pg_partman does address many of the same developer experience items we do, but it doesn't offer things like compression or modified plans. It will perform roughly the same as declarative partitioning (because that's what it uses), and I'm guessing we will see results similar to the last large table (in the Declarative Partitioning section).

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#48

Post by mfreed »

nextaccountic wrote: post #43

Hey, about the column-wide data compression thing. If I have a column with strings that are highly similar to each other (maybe they are urls, maybe they are HTML documents that were scraped from the same site, but they are expected to contain redundancies) What's the best approach to get excellent compression? Can I exploit this redundancy within the column somehow? I don't even know the right search terms for this.…

TimescaleDB supports compression for all data types, it just uses type-aware compression algorithms that it applies automatically/transparently based on typing.

- Gorilla compression for floats

- Delta-of-delta + Simple-8b with run-length encoding compression for timestamps and other integer-like types

- Whole-row dictionary compression for columns with a few repeating values (+ LZ compression on top)

- LZ-based array compression for all other types

https://www.timescale.com/blog/building-columnar-compression...

So as to your question, just turn on compression; it's very common to see 94-97% reduction in storage.

(Timescale co-founder)

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#49

Post by tempnow987 »

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.

Ah, I suppose you'd prefer they switched to Affero GPL v3 (which BTW IS open source and written by FSF itself) - check it out here:

https://www.gnu.org/licenses/agpl-3.0.en.html

This license turns out to be very difficult to use for almost developer.

Re: TimescaleDB 2.7 vs. PostgreSQL 14

#50

Post by LoriP »

znpy wrote: post #9

No mention of ha in the documentation. I can’t understand whether HA would rely on the standard postgresql tooling or if you have to pay for some kind of enterprise license to get it.

Timescale doesn't charge for any of its software. Revenue comes from providing hosting services that are optimized towards TimescaleDB and PostgreSQL at scale.

The code is source-available, license philosophy is explained in this blog post https://www.timescale.com/blog/building-open-source-business...

That includes the HA implementation, and I think someone else shared the docs for that. Hope this helps.

Post reply on HN