3 ms·

Every time TimescaleDB is brought up, I feel the need to point people to their shadily worded proprietary licence[0], and pg_partman[1]. Do the same benchmarks

Every time TimescaleDB is brought up, I feel the need to point people to their shadily worded proprietary licence[0], and pg_partman[1]. Do the same benchmarks against a pg_partman managed partitioned db and you'll get the exact same performance. We do, at least - 150k or so metrics per second, 10 columns per metric. Not trying to crap on the TimescaleDB guys, I've found a lot of their writeups extremely useful and can totally see how their commercially supported product fits. However, I like to see pg_partman at least mentioned somewhere in the article/comments. It's awesome and does the same job. [0]https://github.com/timescale/timescaledb/blob/master/LICENSE https://github.com/timescale/timescaledb/blob/master/LICENSE [1]https://github.com/pgpartman/pg_partman https://github.com/pgpartman/pg_partman

detaro 7y ago
Link to a file that actually contains said license: https://github.com/timescale/timescaledb/blob/master/tsl/LICENSE-TIMESCALE https://github.com/timescale/timescaledb/blob/master/tsl/LIC...
- cevian 7y ago
  Clarification: this license is only for Community and Enterprise Features that live in the `tsl` subdirectory. The vast majority of our code (everything not under `tsl`) is licensed under Apache 2.
- deleted 7y ago
  [deleted]
mfreed 7y ago
(Timescale cofounder here) Hey, just wanted to clarify: the vast majority of TimescaleDB code is Apache2, and you can easily compile (and we ourselves build & distribute) Apache2-only binaries. When we announced a new license in December, we didn't relicense any code, we just said that some future features will be available under a Community or Enterprise License. The code under this "Timescale License" is clearly marked and in a separate subdirectory, and for virtually all users (except the public cloud DBaaS providers), the community features are free. This is the actual top-level LICENSE file in the repo: https://github.com/timescale/timescaledb/blob/master/LICENSE https://github.com/timescale/timescaledb/blob/master/LICENSE And here's a blog post discussing in more depth: https://blog.timescale.com/how-we-are-building-an-open-source-business-a7701516a480/ https://blog.timescale.com/how-we-are-building-an-open-sourc...
- boomskats 7y ago
  Thanks for the response & clarification, I'll give the blog post a read.
- GordonS 7y ago
  Timescale user here. I actually think your "community" TSL license and Enterprise licenses are a good compromise. Perhaps what's not immediately obvious is that the TSL license is there to protect against cloud providers offering hosted TimescaleDB without contributing back - systems that add value (e.g. are backed by TimescaleDB for DML) can use TSL-licensed code without any issue.
cevian 7y ago
(TimescaleDB engineer here) There are major feature and capabilities available in TimescaleDB that are not available in pg_partman. On the query side we implement a whole bunch of planner and execution time optimizations that don't come with plain PostgreSQL (and pg_partman does not implement any query optimizations AFAIK). These include optimizations that have to do with ordering based on time_bucket/date_trunc, execution-time chunk exclusion, etc. These result in query speedups of more than 1000x on many common time-series queries. TimescaleDB is much more automated than pg_partman and thus easier to maintain and administer. There are a lot less knobs to tune and a lot less things to go wrong in TimescaleDB. We implement analytical features necessary for time-series analyis: gap-filling, common time-series functions liked time_bucket, first, last, etc. We also implement a lot of data management functionality geared towards time-series data: scheduled data reordering, schedule data dropping/expiration, etc. This past Monday we released major feature called continuous aggregates. That automatically maintain a materialized view of aggregates over your time-series data, updating it as new data comes in and correctly handling backfilled data as well. The two projects are really not comparable in breadth or scope IMHO.
- deleted 7y ago
  [deleted]

detaro 7y ago

Link to a file that actually contains said license: https://github.com/timescale/timescaledb/blob/master/tsl/LICENSE-TIMESCALE https://github.com/timescale/timescaledb/blob/master/tsl/LIC...

cevian 7y ago
Clarification: this license is only for Community and Enterprise Features that live in the `tsl` subdirectory. The vast majority of our code (everything not under `tsl`) is licensed under Apache 2.
deleted 7y ago
[deleted]

mfreed 7y ago

(Timescale cofounder here) Hey, just wanted to clarify: the vast majority of TimescaleDB code is Apache2, and you can easily compile (and we ourselves build & distribute) Apache2-only binaries. When we announced a new license in December, we didn't relicense any code, we just said that some future features will be available under a Community or Enterprise License. The code under this "Timescale License" is clearly marked and in a separate subdirectory, and for virtually all users (except the public cloud DBaaS providers), the community features are free. This is the actual top-level LICENSE file in the repo: https://github.com/timescale/timescaledb/blob/master/LICENSE https://github.com/timescale/timescaledb/blob/master/LICENSE And here's a blog post discussing in more depth: https://blog.timescale.com/how-we-are-building-an-open-source-business-a7701516a480/ https://blog.timescale.com/how-we-are-building-an-open-sourc...

boomskats 7y ago
Thanks for the response & clarification, I'll give the blog post a read.
GordonS 7y ago
Timescale user here. I actually think your "community" TSL license and Enterprise licenses are a good compromise. Perhaps what's not immediately obvious is that the TSL license is there to protect against cloud providers offering hosted TimescaleDB without contributing back - systems that add value (e.g. are backed by TimescaleDB for DML) can use TSL-licensed code without any issue.

cevian 7y ago

(TimescaleDB engineer here) There are major feature and capabilities available in TimescaleDB that are not available in pg_partman. On the query side we implement a whole bunch of planner and execution time optimizations that don't come with plain PostgreSQL (and pg_partman does not implement any query optimizations AFAIK). These include optimizations that have to do with ordering based on time_bucket/date_trunc, execution-time chunk exclusion, etc. These result in query speedups of more than 1000x on many common time-series queries. TimescaleDB is much more automated than pg_partman and thus easier to maintain and administer. There are a lot less knobs to tune and a lot less things to go wrong in TimescaleDB. We implement analytical features necessary for time-series analyis: gap-filling, common time-series functions liked time_bucket, first, last, etc. We also implement a lot of data management functionality geared towards time-series data: scheduled data reordering, schedule data dropping/expiration, etc. This past Monday we released major feature called continuous aggregates. That automatically maintain a materialized view of aggregates over your time-series data, updating it as new data comes in and correctly handling backfilled data as well. The two projects are really not comparable in breadth or scope IMHO.

deleted 7y ago
[deleted]