Live data from Hacker News

Multi-node TimescaleDB is now free

blog.timescale.com

171–180 of 220 posts

Re: Multi-node TimescaleDB is now free

#171
post #136

Correct me if I am wrong. Timescale DB Core ( if there is such a thing ) is still available under Apache 2.0. So nothing has changed. You can use it just like any other open source project with no restriction. Timescale DB multi-node, originally not free and only available in Timescale Cloud. Is now Freely available under the Timescale License, a source-available license. Timescale DB multi-node and its license only…

Almost!

Yes, TimescaleDB "core" - still Apache 2.0

TimescaleDB multi-node - was never before released, is now released for free under the Timescale License, a source-available license

There are other capabilities (e.g., gap-filling) that are also under the Timescale License, in addition to multi-node.

The Timescale License prevents "TimescaleDB-as-a-service" usage.

You can still run software / services on top of Timescale Licensed software, as long as you are not offering "TimescaleDB-as-a-service".

The Timescale License currently prevents running any modifications in production, but we are actively debating removing that restriction (as I mention elsewhere).

Hope this helps.

Re: Multi-node TimescaleDB is now free

#172
post #130

Earlier quoted context omitted.

Hi JeremyNT: We've never "changed" any Apache-2 licensed code to TSL-licensed code. And in fact, we've recently basically eliminated most of our enterprise features (read: paid only) and converted them to community features (read: free under the TSL). So I'm curious: Why do you use only the Apache-2 version of TimescaleDB rather than the Community version? https://www.timescale.com/products/features (I realize that I…

First, thanks for replying. But, I'll note you didn't answer my question, which is about the future of the current open source codebase. Knowing that you haven't changed the license on such code yet is great, but that doesn't speak to the future direction for that codebase. EDIT: I just saw this reply to another child, which addresses this concern for the core timescale, I think! [0] To be clear, I don't think the li…

Just to clarify, the Timescale License was originally announced in December 2018. At that time, we didn't "relicense" any existing Apache-2 code, we just said some future features will be licensed under the TSL rather than Apache 2.

Many people over the past year+ knew that we were working on a distributed version of TimescaleDB; a common question was whether the distributed TimescaleDB would be paid-only (like some other time-series database alternatives) or whether it would also be free.

This announcement was meant to say: Yes, multi-node TimescaleDB is free, not paid.

So there wasn't any _new_ license announced today; just that multi-node TimescaleDB would be released under the TSL rather than as a paid-only option, which many of our users had assumed.

Re: Multi-node TimescaleDB is now free

#173

Earlier quoted context omitted.

Just so that everything is 100% clear, most of our code base is still Apache 2 licensed (and we have no plans to change that). All that this blog post is (trying) to say is that multi-node will not be under a paid license, but instead will be free under the Timescale License. Hope this helps.

Thanks very much for clarifying. You might want to make a note of this in the blog post!

Fair enough, will do!

Re: Multi-node TimescaleDB is now free

#174
post #139

Earlier quoted context omitted.

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…

We took great effort to try to draw a clear line within the actual Timescale License language [0].

Usage is permitted, as long as:

  the [end-]customer is prohibited, either contractually or technically, from
  defining, redefining, or modifying the database schema or other
  structural aspects of database objects, such as through use of the
  Timescale Data Definition Interfaces, in a Timescale Database utilized by
  such Value Added Products or Services.
In other words, if your service just provides DML access (read/write/modify), then that is permitted, while DDL access (modifying/creating schemas) is not permitted.

And in fact we already have thousands of companies building commercial applications on top of Timescale Licensed software (while adhering to the license).

[0] https://github.com/timescale/timescaledb/blob/master/tsl/LIC...

Re: Multi-node TimescaleDB is now free

#175

How does TimescaleDB work as a traditional OLTP db? Can I run general analytical queries on it and leverage its distributed nature? Or is it better for single table append only workloads?

The Hypertables and Distributed Hypertables can be used to store any kind of data, but works best as long as it has a monotonously increasing partitioning key (e.g. time), with high ingest load, few data modifications (preferable bulked) The beauty of TimescaleDB being built on Postgres is you can have your regular Postgres tables (OLTP schema) and time-series data (Hypertables) live side by side. Use 1 language (1 m…

Continuous aggregates look like a killer feature.

Re: Multi-node TimescaleDB is now free

#176

I saw that TimescaleDB is mostly C, like other PG extensions. Have you all put any thought into using Rust? Just curious about why or why not.

TimescaleDB uses heavily PostgreSQL API and hooks, which expose many data structures, macros and functions. My understanding is that using Rust or even C++ will require to write large FFI and also maintain it between PG major versions, which are released every year. Also, just having FFI is unlikely enough, and will require to write wrappers on top of it to use the best of Rust and not just another syntax on top of C.

Re: Multi-node TimescaleDB is now free

#177
post #138

Earlier quoted context omitted.

Frankly the pedantry around the definition of Open Source, which I understand, is incredibly nauseating. Sure, this isn't Open Source by "the definition", but it's close enough if you squint. The difference doesn't impact almost anyone. Are you or someone you love impacted by this licensing decision? Throw in an expiry date, dual licensing (pay to play seems more than fair) and I'm content. History be damned. I'm so…

> pedantry around the definition of Open Source, which I understand ... it's close enough if you squint Then I think that while you might have read and understood the definition, you seem to have missed the broader idea behind it. > pay to play seems more than fair That's irrelevant. Sure it's fair, but it's fundamentally _not open source_. It's not about gospel or having power over you. It's about communication and…

> you seem to have missed the broader idea behind it.

Funny, I feel that you might have missed the point as well.

> It's about communication and well established meanings.

Yes, but it's fundamentally impossible to bucket various licenses into what they do and do not do, and what obligations or burdens they place upon the end user. What is Open Source? The OSI includes GPLv3, which is certainly not "free" for a ton of commercial uses.

Let's peek at the OSI's FAQ:

> This history has led to occasional confusion about the relationship between the two terms. Sometimes people mistakenly assume that users of the term "open source" do not intend to communicate a philosophical point of view via that term, even though many actually do use it that way. Another mistake, which has occasionally been seen since about 2008, is to assume that "free software" refers only to software licensed under copyleft licenses, since that is how the FSF typically releases software, while "open source" refers to software released under so-called permissive (i.e., non-copyleft) licenses. In fact, both terms refer to software released under both kinds of license.

> Neither term binds exclusively to one set of associations or another, however; it is always question of context and intended audience. When you sense a potential misunderstanding, you may wish to reassure your audience that the terms are essentially interchangeable, except when being used specifically to discuss the history or connotations of the terminological difference itself. Some people also prefer to use the term "free and open source software" (or FOSS, FLOSS [free, libre and open source software]) for this reason.

Okay so, let's recap: A) it's confusing. B) the terms are often interchangeable but context matters. C) not everyone agrees.

At this point, the value of any "Open Source Definition" is severely diluted for any considerable purpose. Just because a license meets OSI's definition doesn't mean I should make any assumptions about what I can or cannot do with it, so what value does this provide beyond adding confusion?

> Can I call my program "Open Source" even if I don't use an approved license? > Please don't do that. If you call it "Open Source" without using an approved license, you will confuse people. This is not merely a theoretical concern — we have seen this confusion happen in the past, and it's part of the reason we have a formal license approval process. See also our page on license proliferation for why this is a problem.

I'd argue the confusion is already present. A license is a license is a license. OSI is an organization that says "please don't call your thing Open Source if it doesn't meet our standards" -- I don't care. Whether or not I comply with this polite request changes nothing, offers me no direct benefits.

To be clear: I see value in OSI, and everything they provide. They have definitely provided a net benefit to the world. I do not see value in pedantry around the term "open source", those words are so plain and ordinary that gluing any tertiary meaning to them is foolish. It's as subjective as "good code".

Re: Multi-node TimescaleDB is now free

#178

Earlier quoted context omitted.

> I think we're too hung up on OSI open source licenses. I disagree. The free software criteria were defined as they are for a reason. AWS and other cloud vendors are taking advantage, but that is not a good reason to give up on the ideals of the movement. I would be much more comfortable contributing to timescaledb if the license had a date at which it expired to AGPL or some other OSI/DFSG/fourfreedoms license.

In principle, yes I agree, but in practice: no! AGPL is a minefield, it's a shame it is, but it is. The spirit of GPL (and AGPL) was that you could do whatever you want but you have to release the source, but they have continually been handicapped by the evolution of software. Existing licenses are not appropriate for SaaS businesses, they are either too liberal or too restrictive. What you're seeing here is the righ…

> The spirit of GPL (and AGPL) was that you could do whatever you want but you have to release the source, but they have continually been handicapped by the evolution of software.

This was largely my assessment, as well. And the motive behind the work that led to Parity (https://paritylicense.com).

Re: Multi-node TimescaleDB is now free

#179

Earlier quoted context omitted.

The Hypertables and Distributed Hypertables can be used to store any kind of data, but works best as long as it has a monotonously increasing partitioning key (e.g. time), with high ingest load, few data modifications (preferable bulked) The beauty of TimescaleDB being built on Postgres is you can have your regular Postgres tables (OLTP schema) and time-series data (Hypertables) live side by side. Use 1 language (1 m…

Continuous aggregates look like a killer feature.

Thanks! You might also find this related feature, real-time aggregation, really powerful as well.

We just released it last month: https://blog.timescale.com/blog/achieving-the-best-of-both-w...

"With real-time aggregation, when you query a continuous aggregate view, rather than just getting the pre-computed aggregate from the materialized table, the query will transparently combine this pre-computed aggregate with raw data from the hypertable that’s yet to be materialized. And, by combining raw and materialized data in this way, you get accurate and up-to-date results, while still enjoying the speedups that come from pre-computing a large portion of the result."

Re: Multi-node TimescaleDB is now free

#180
post #137

Earlier quoted context omitted.

Absolutely! We wrote one of the first remote backends to Prometheus that supports both the remote_read/remote_write interface: https://prometheus.io/docs/operating/integrations/#remote-en... Given how much interest we had using TimescaleDB for this, we recently built and released (in beta) a new "full-stack" of Prometheus + TimescaleDB + Grafana that comes fully configured and "just works" out-of-the-box: - https://t…

This is so nice that design doc is opened for commenting - so much good thoughts there. Thank you for sharing! After reading that I have a two questions: 1. While the integration with Prometheus sounds great it still requires to run pretty complicated system behind it. The distributed TimescaleDB could require a lot of knowledge to operate and additionally a connector that could become a one more point of failure. Ha…

1. Even though it is newer, distributed TimescaleDB is probably more robust and easier to operate (and already more operationally mature) than other local storage options for Prometheus metrics, in part thanks to the underlying maturity of Postgres.

2. Yes, supporting PromQL directly (ie not via remote_read) is already in internal testing. Coming very soon.

Would really appreciate feedback if/when you get to try it out yourself. Please feel free to ping me directly: ajay (at) timescale.com

Post reply on HN