Hacker News new | past | comments | ask | show | jobs | submit login

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

[1]https://github.com/pgpartman/pg_partman




(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

And here's a blog post discussing in more depth: https://blog.timescale.com/how-we-are-building-an-open-sourc...


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.


Thanks for the response & clarification, I'll give the blog post a read.


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


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


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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: