Multi-node TimescaleDB is now free • Hacker News Board

Re: Multi-node TimescaleDB is now free

#121

Post by z3t4 » Fri, May 22, 2020, 6:43 PM UTC

lukevp wrote: post #104

pritambaral wrote: post #100

Earlier quoted context omitted.

> I have never ... _You_ may not have, but plenty of us have. Although, it's not as important when or how many times one has _needed_ to exercise one's freedoms, as it is to have them. But yes, plenty of us open-source users and supporters have exercised this very freedom. In fact, quite a lot of open-source contributions happen _because_ of this freedom: someone has an itch, they scratch it, and _then_ they upstream…

Is that not possible under this license, to upstream a change? It sounds like you can’t put the change into production without it first being accepted, but not that you couldn’t contribute in other ways. I get the spirit of your argument. However, the issue is that companies are not able to make open-source compatible, permissive licenses that allow commercial use due to the new reality that creating a service and su…

I run a bunch of forks in production that the maintainers didn't want to merge in. Then they made breaking changes... Software doesn't necessary need to be updated all the time. Adding more features often make the program slower and break stuff, the hardest part of dev is to say no to new features, its much easier to implement new features then solving though problems.

Re: Multi-node TimescaleDB is now free

#122

Post by kev009 » Fri, May 22, 2020, 6:43 PM UTC

eloff wrote: post #58

kev009 wrote: post #36

Earlier quoted context omitted.

I think you are being a bit generous on the causes and effects. The #1 concern of a product like this is adoption. Not in some unsustainable subsidized taxi or food delivery type thing, just that data stores are naturally sticky and come with long term opportunity as usage grows. If they dominate the time series use case, and there is good reason to believe they will, earning revenues will fall out of that in a multi…

I don't think it's FOSS+support, more like a cloud database service offering. Time will tell I suppose as to which business model dominates. And one could make the argument the service is a form of support.

My own experience is the majority of people are using it on their own cloud instances, on prem, or embedded. It's not obvious the first-party aaS will catch on right now, just like the novel license. I don't mean any of this negatively, it's clearly a well run business by smart people that are experimenting with revenue models and trying to achieve the fair outcomes for customers and the business.

Re: Multi-node TimescaleDB is now free

#123

Post by mfreed » Fri, May 22, 2020, 6:45 PM UTC

amenod wrote: post #103

pritambaral wrote: post #66

Earlier quoted context omitted.

> 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. I don't care if I can see the source code if I can't actually _do_ anything with it. If I can't run my modifications in production, it doesn't guard me against vendor lock-in and it doesn't give me the right-to-repair. So what's the benefit? Note that I am not arguing for OSS licences, but something like the Commons Clause (use freely, even for commercial use, repair as you wish, just don't sell) seems much mor…

We did consider the Commons Clause when investigating our own licensing approach, but ended up concluding that its definition of "Sell" were actually much vaguer than we felt comfortable with:

  “Sell” ...a product or service whose value derives, entirely or 
  substantially, from the functionality of the Software.

I realize that opinions might differ, though.

Re: Multi-node TimescaleDB is now free

#124

Post by solidasparagus » Fri, May 22, 2020, 6:46 PM UTC

nojvek wrote: post #64

akulkarni wrote: post #16

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…

I admire the `except the cloud providers`. What GCP, Azure and AWS have done with paid Redis offerings make me curious what @antirez (Salvator) thinks about it. They're making billions off Redis while the core contributors get nothing. I guess they agreed to it by having their work as BSD licence. I do think there is a place for royalty based software. Free for personal and development use. For production use, you pa…

> while the core contributors get nothing

Running a half-billion dollar company after raising $150M in funding is not nothing.

Re: Multi-node TimescaleDB is now free

#125

Post by valyala » Fri, May 22, 2020, 6:50 PM UTC

gigatexal wrote: post #65

atanasovskib wrote: post #52

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…

This sounds like the perfect fit to a write only event log table we stored in postgres at a previous employer. I pushed to move it to BigQuery but this sounds like it would have been fine.

There is more cost effective alternative to BigQuery for storing and analyzing big amounts of logs - LogHouse [1], which is built on ClickHouse.

[1] https://github.com/flant/loghouse

Re: Multi-node TimescaleDB is now free

#126

Post by mfreed » Fri, May 22, 2020, 6:50 PM UTC

jakaroo wrote: post #101

mfreed wrote: post #85

Earlier quoted context omitted.

In the current version, you can execute `compress_chunks` on each of the data nodes and enjoy those same savings (and will work transparently with queries, as before). In subsequent releases, we'll add full support of compression, e.g., just create a compression policy on the access node and you are off and running.

Sounds great. So I just manually execute this `compress_chunks` command once on each data node and then I have compression enabled forever on those nodes?

Not yet, I should have been clearer:

compress_chunk operates on a single chunk, the way to define "compress all chunks older than 1 week is":

   SELECT compress_chunk(i) from show_chunks('conditions', older_than => INTERVAL '1 week');

https://docs.timescale.com/latest/using-timescaledb/compress...

So you'd need to setup a cron job that runs that script every night or something...at least until we release compression policy support.

Re: Multi-node TimescaleDB is now free

#127

Post by mfreed » Fri, May 22, 2020, 6:50 PM UTC

gregmac wrote: post #108

lukevp wrote: post #96

Earlier quoted context omitted.

Is this really an issue in practice? For libraries (react, jquery) that can’t be used on their own as a product, a lot are adopting MIT. For a “service” - mongodb, redis, rabbitmq, Kafka, Postgres, etc. I have never run into an issue where I would be comfortable modifying something, rebuilding source and deploying into production.

It's also a hedge against the company/project shutting down or pivoting in a radically different direction than you want. All the things you listed are foundational pieces of technology that are incredibly risky+costly to swap out, so if you needed to, there's an option to continue with a fork. If the thing is popular enough, there's a good chance a community-driven effort will pop up, you can find consultants to wor…

A slightly different perspective of our licensing/copyright approach is there isn't confusion about ownership, so if we were ever to decide on a more permissive license, we have the clean ability to do so.

Zero plans, but this also applies if a company like ours were to ever pivot/shut down: we as copyright holders can just relicense _all_ the code to be more permissive / dual licensed / etc, which is not the case for projects where individuals hold copyright over merged contributions. (Note the opposite is not true: we can't "unrelease" versions of the code already released under a more permissive license, such as how most of our code-base in Apache 2.)

In short, I understand your point, but I think there are actually multiple sides to this issue as well.

Re: Multi-node TimescaleDB is now free

#128

Post by heipei » Fri, May 22, 2020, 6:51 PM UTC

mfreed wrote: post #109

heipei wrote: post #91

Earlier quoted context omitted.

OK, but it looks like I still have to define these aggregates manually. I was really more talking about the standard use-case that folks used to use Graphite / rrdtool for: Keep track of real-time high-fidelity metrics while still being able to query aggressively-downsampled historical data for comparison, and doing so without having to configure anything.

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) and just hit "go", much like would with something like Datadog, and have the confidence that they can still scale the database if its ever necessary. Much like ElasticSearch provides default mappings (text/keyword/date/number), this would a great 80-20 solution for the default use-case of "I want to collect system metrics from my hundreds of servers and have a few sensible defaults about granularity, downsampling and data-retention, and only then will I start to worry about whether that data will eventually exceed my one-server deployment."

Re: Multi-node TimescaleDB is now free

#129

Post by hagen1778 » Fri, May 22, 2020, 6:53 PM UTC

Free multi-node TSDB solution sound cool! I wonder if someone tried to use TimescaleDB as remote-storage for some heavy-loaded Prometheus [1] setups.

[1] https://prometheus.io/

Re: Multi-node TimescaleDB is now free

#130

Post by mfreed » Fri, May 22, 2020, 6:53 PM UTC

JeremyNT wrote: post #113

akulkarni wrote: post #16

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…

Hi there! We use and love Timescale, so we've been paying attention to this feature. We currently use the open source version and it's very nice. Would you mind clarifying a bit, because the blog post doesn't really explain: how much of TS do you expect to remain Open Source versus proprietary? Is the idea here that you will switch the entire project to this new license (i.e., this means you're killing the open sourc…

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'm saying "TSL-licensed" versus proprietary, because I'm not sure what it means to think of the code as proprietary when it's all source available on github, people can contribute, and 99% of companies just use it for free.)