Live data from Hacker News

Multi-node TimescaleDB is now free

blog.timescale.com

151–160 of 220 posts

Re: Multi-node TimescaleDB is now free

#151

Earlier quoted context omitted.

(Timescale CEO and post author) You are spot on. Before the Timescale License, we were left with a tough decision: do we open-source a feature so that everyone can have it for free OR do we close a feature so that the mega-clouds don't have access to it? We didn't like either of those options, which is why we created the Timescale License, which allows us to offer capabilities for free (and make the source code avail…

> and make the source code available It's available to _see_, but not to "prepare, compile, and test Derivative Works of the TSL Licensed Software Source Code" in a production environment, as per your license's clause 2.1 (d). That's a pretty big departure from open-source; and a bit discouraging for use by non-mega-cloud business interests too. One of the important reasons I personally use and support open-source is…

This is a completely valid point. I also appreciate the "right-to-repair" comment made elsewhere.

The original intent of this clause was so that we wouldn’t have to support modified versions that were deployed to production. (As pointed elsewhere, we provide a lot of free support in Slack [0].)

But that clause was written 1.5 years ago, and a lot has changed since then. There’s an internal debate right now on whether we should remove this restriction.

So thank you for asking this question!

[0] https://slack.timescale.com/

Re: Multi-node TimescaleDB is now free

#152

I really appreciate that the linked article uses the phrasing "source-available", the lower case "free", and doesn't use the phrase "open source". Terminology matters a lot. For me, a lot of the value in Free software comes from being able to make modifications to the software (either yourself, or by hiring others), and generally being in control of your own "software destiny". With that in mind, I think it's importa…

Thanks for drawing attention to Clause 2.1 (d). The original intent of that clause was to avoid us needing to support modified versions that were deployed to production. (Note: We provide a lot of free support in our 4000+ member Slack channel [0].) But that clause was written 1.5 years ago, and a lot has changed since then. There’s actually an internal debate right now on whether we need to keep it. So thank you and…

If you intend to change it to allow running open-sourced changes, you might consider allowing changes submitted to you privately too, for vulnerability reports.

Re: Multi-node TimescaleDB is now free

#153
post #139

Earlier quoted context omitted.

(Timescale CEO and post author) You are spot on. Before the Timescale License, we were left with a tough decision: do we open-source a feature so that everyone can have it for free OR do we close a feature so that the mega-clouds don't have access to it? We didn't like either of those options, which is why we created the Timescale License, which allows us to offer capabilities for free (and make the source code avail…

Disclosure: I work on Google Cloud (but am glad to see you protecting your rights to your software). The conversation down thread though raises an interesting point: why does the license say you can’t run modifications in production (under any circumstances) versus some sort of “for commercial purposes” clause? It seems to me like it’s infeasible to have actual contributions if someone isn’t allowed to have a patch,…

It's a good question. How do we classify non-commercial? Is a telecom company using timescaledb for internal time series storage non-commercial although it is directly supporting a commercial offering (maybe mobile traffic platforms)?

I do get the direct commercial inference. What about the indirect ones? Just about anything in production is directed towards supporting some sort of commercial offering.

Just genuinely curious...

Re: Multi-node TimescaleDB is now free

#154

What's the difference between Timescale's license ("free to everyone except cloud providers") and GPLv3?

The differences are pretty substantial. The GPL puts no restrictions whatsoever on how you can use software that falls under it. Timescale's license, on the other hand, gives you very limited usage rights. You can use unmodified versions of the software, but you can't allow clients to make schema changes, nor can you use it to provide any service that is "primarily [a] database storage or operations product or servic…

Changes you make to GPL software only have to be provided under the GPL if you redistribute the work to others- if you keep it to yourself, run it yourself, etc, you are not required to release it as GPL.

Re: Multi-node TimescaleDB is now free

#156

Why should someone use TimescaleDB over ClickHouse for time-series/analytics workloads?

I've heard several points for not choosing ClickHouse and going to TimescaleDB as an extension of PostgreSQL:

1. As it is already mentioned, if metadata (data about timeseries) are already in PostgreSQL, then it is nice to stay in the same database engine for querying data with joins of both metadata and timeseries data, so there is no need to implement integration of the two source in the application layer.

2. Also related to the first item: advantage of already knowing PostgreSQL API. ClickHouse has different management API, so it is necessary to learn. While if you know PostgreSQL, you don't need to learn new management API and only timeseries specific API of TimescaleDB.

3. ClickHouse doesn't support to update and delete of existing data in the same way as relation databases.

Then the final decision still depends on your need.

Re: Multi-node TimescaleDB is now free

#157
post #139

Earlier quoted context omitted.

(Timescale CEO and post author) You are spot on. Before the Timescale License, we were left with a tough decision: do we open-source a feature so that everyone can have it for free OR do we close a feature so that the mega-clouds don't have access to it? We didn't like either of those options, which is why we created the Timescale License, which allows us to offer capabilities for free (and make the source code avail…

Disclosure: I work on Google Cloud (but am glad to see you protecting your rights to your software). The conversation down thread though raises an interesting point: why does the license say you can’t run modifications in production (under any circumstances) versus some sort of “for commercial purposes” clause? It seems to me like it’s infeasible to have actual contributions if someone isn’t allowed to have a patch,…

The original intent of that clause was to help us avoid needing to support modified versions that were deployed to production.

And we tend to offer a lot of free support, e.g., via our 4000+ member Slack channel [0]. We like making sure TimescaleDB users are happy.

But that clause was written 1.5 years ago, and a lot has changed since then.

There’s actually an internal debate right now on whether we need to keep it. So thank you and HN for spurring this discussion!

[0] https://slack.timescale.com/

Re: Multi-node TimescaleDB is now free

#158
post #152

Earlier quoted context omitted.

Thanks for drawing attention to Clause 2.1 (d). The original intent of that clause was to avoid us needing to support modified versions that were deployed to production. (Note: We provide a lot of free support in our 4000+ member Slack channel [0].) But that clause was written 1.5 years ago, and a lot has changed since then. There’s actually an internal debate right now on whether we need to keep it. So thank you and…

If you intend to change it to allow running open-sourced changes, you might consider allowing changes submitted to you privately too, for vulnerability reports.

Thanks for the input, will bring it back to the team for discussion.

(Note: I really appreciate getting this kind of feedback openly from the community, so thank you :-)

Re: Multi-node TimescaleDB is now free

#159
post #128
post #109

Earlier quoted context omitted.

Hi @heipei -- one thing to observe is that Graphite & rrdtool are designed for a specific monitoring use case, while TimescaleDB is a more general-purpose time-series database. So what that means is that TimescaleDB has mechanisms to make it really easy to define downsampling (continuous aggregates, data retention policies), and even have queries that transparency query across the historical aggregates and new raw da…

Thanks for the pointer. I truly understand that TimescaleDB is a general-purpose time-series DB and I understand that most use-cases are unique in that it makes sense to make these decisions about what and how to downsample consciously. However, I feel that there is a large audience of people who "just" want a database that they can point their system-metrics collector at (Telegraf), point their dashboard at (Grafana…

Yep, that's exactly what the "Timescale Observability" stack is about. Type "helm install", and a full stack is spun-up and auto-configures to scrape information. You have graphs up in Grafana within 2 minutes, zero configuration.

- See https://github.com/timescale/timescale-observability

- Or join the #prometheus channel at https://slack.timescale.com

Re: Multi-node TimescaleDB is now free

#160

Why should someone use TimescaleDB over ClickHouse for time-series/analytics workloads?

That's a good question! Especially considering these overwhelming benchmarks [1] made via Timescale TSBS [2]. [1] https://www.altinity.com/blog/clickhouse-for-time-series [2] https://github.com/timescale/tsbs

Those 2018 benchmarks pre-dated many of the features we released last year, including columnar compression, continuous/real-time aggregates, etc.
Post reply on HN