Live data from Hacker News

Multi-node TimescaleDB is now free

blog.timescale.com

191–200 of 220 posts

Re: Multi-node TimescaleDB is now free

#191

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…

You could drop it, but require changes to be submitted back or themselves be source available.

Re: Multi-node TimescaleDB is now free

#192
post #182

Earlier quoted context omitted.

You are either severely misunderstanding or misrepresenting the FAQ that you quoted. It's simply clarifying that copy-left and permissive licenses are both compatible with the meaning of the term open source (ie they're disjoint subsets). Regarding the "please only used approved licenses bit" - you've again missed the point. There is an effectively infinite set of possible licenses which satisfy the meaning of the te…

I don't really want to debate with you here, and if anything I feel like the points you are hammering on just fortify my stance that this topic is a waste of breath. > The OSI is merely pointing out that it will make everyone's lives easier if developers try their best to use one of the licenses that already exists Maybe, maybe not! Perhaps existing licenses are not sufficient. I doubt we'll be using the same license…

You say you don't want to debate here, but from my perspective you're actively spreading misinformation and FUD.

I agree that there might be better possible licenses out there - you might notice that I described the set of possible open source licenses as being infinitely large! The point is that you should go with an existing license for the good of the community unless you run into a limitation for your particular usecase that isn't adequately addressed.

Note that this has happened before! It's how the MPL (non-viral) and AGPL (anti proprietary SaaS) came about for example.

The one thing they all have in common is that they protect the user's right to modify and redistribute the software they receive. Yes, that necessarily places some limits on things in order to disallow abridging such rights for downstream users.

Moreover, there is indeed a balance between the degree to which such rights are preserved versus the number of restrictions the license must impose in order to accomplish its purpose. This is why a range from copyleft to permissive exists, with the MPL squarely in the middle. The presence of such nuance doesn't make the definition fuzzy or unclear though - there is a consistent protection of user freedom throughout, with restrictions existing only to further this goal. (Compare this to source available licenses, which carry additional restrictions unrelated to preserving user freedom.)

> Grouping AGPL and MIT in the same bucket is borderline harmful -- they're wildly different! This is what I mean when I say the term "open source" is a fuzzy descriptor. You can't have a fuzzy descriptor and then complain about things which don't fit your worldview. That's what the OSI basically does in a nutshell with their "Open Source Definition".

Again, this is a factually incorrect statement. You are verifiably and demonstrably wrong here. The definition of open source is consistent, and all of those licenses fit it. Source available licenses, on the other hand, do not.

You mention a bunch of objections you (and others) have to AGPL, GPL, etc. That's fine, and those licenses may not be right for you, but that doesn't somehow make them "not open source". Trying to shoehorn in some other definition by claiming that having issues for you or someone else makes them "not open" isn't a valid line of argument. The meaning of the term is very well established at this point and you are misusing it.

I realize you have (apparently) an ideological axe to grind against viral licenses. I don't particularly like them either, but that doesn't magically change the definition of an established term.

> The term you're looking for is "I disagree".

No, I used precisely the term I was looking for when I said that you were incorrect. It is true that I disagree with all of your following statements as a result though! You might legitimately hold that the term "open source" has a different definition than the one I use, but (as you might have gathered from what I wrote) I'm not even remotely convinced. In fact I made it clear that I hold such views to be ignorant, and that I believe you have fundamentally misunderstood the entire point of the open source movement. I can see how such a view might come off as abrasive, but that doesn't change it.

Re: Multi-node TimescaleDB is now free

#193

Earlier quoted context omitted.

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 :-)

One possible approach compatible with true software freedom and the usual definition of open source is not to restrict use of modified versions of the code, but instead to use naming to distinguish between the two, and only support the unmodified version. For example, the code build system could have variables for the name and maybe the logo and other trademark/brand-ish things, and the public codebase could be confi…

It's an interesting idea. We'll consider it. Thanks!

Re: Multi-node TimescaleDB is now free

#194

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…

Could you not just say "we don't support modified versions"? This seems like throwing the baby out with the bathwater a bit.

It's a dual-edged sword: Not supporting modified versions means that there are potentially unhappy users.

But we also understand the motivation behind wanting to run a modified version.

This is something we are now actively discussing internally.

Thanks!

Re: Multi-node TimescaleDB is now free

#195
post #185

Earlier quoted context omitted.

@jcims I'm really interested to see if we can help. If you're open to discussing, please feel free to email me: ajay (at) timescale.com

It wouldn't be me reaching out but I'll put a bug in the right person's ear. This has been something I've been thinking about for a bit, the HN post is just a bit serendipitous.

Sounds good, thanks!

Re: Multi-node TimescaleDB is now free

#196

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/

You may also want to checkout https://eng.uber.com/m3 which is a highly available RF=3 multi-node TSDB metrics backend and is used with heavy Prometheus workloads and is used to ingest tens of millions of timeseries per second.

Re: Multi-node TimescaleDB is now free

#197
post #70
post #40

Earlier quoted context omitted.

I'm a huge fan of Splunk but always want to keep my eye open for alternatives. My use case is mostly security analytics against event content and patterns, and for that the Splunk Processing Language is very well suited. That said I find it's fairly tedious to do a lot of time-series analysis and pattern discovery/anomaly detction across rich event models (think aws cloudtrail events). Anything TimescaleDB can help w…

I use TimescaleDB for mass storage and query of security events (up to 100s of millions) - the speed of queries and aggregate queries even on a single node is very impressive. I haven't done anything with regards to anomaly/trend detection yet, but it's planned. Not really sure where you see a database (TimescaleDB) fitting into that though?

Hi GordonS, would love to hear about your use case if you don't mind sharing! ajay (at) timescale.com

Re: Multi-node TimescaleDB is now free

#198

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/

I've had luck with https://thanos.io/ for a big (~1 billion timeseries across all our DCs) Prometheus scale out project. Horizontally sharded Prometheus that can be queried and alerted on in a unified view with object store backend.

Re: Multi-node TimescaleDB is now free

#199
Very happy to see Timescale making more features available in the community edition.

We first started evaluating time series databases a month or two ago, some features like continuous aggregation (rollups) were enterprise only. Perhaps their strategy is to drive adoption and letting people try their feature out, hoping that some of these adoptors will end up using their managed solution. I checked their pricing, and the delta between their pricing and the underlying AWS instance seems quite reasonable.

We ended up testing Influx first, because it seems to be a safe choice with wider adoption and extensive documentation.

With Influx, it was very easy to put together a prototype quickly. But once we started throwing some real workload at it, it would lose writes under load. But it makes sense that it failed, because according to Influx's documentation (https://docs.influxdata.com/influxdb/v1.8/guides/hardware_si...), we would need cluster to make it work. Influx is very transparent in their documentation that writes and queries will fail immediately when a server is unavailable without cluster.

This isn't to say that Influx wouldn't work for other use cases. But at least in our use case, their open source offering isn't suitable for us, and it's unclear how much better the cluster version is.

Timescale, on the other hand, was able to handle the same workload under stress. As we are unable to backfill some of the ingressing data, it's quite vital that the system can degrade more gracefully.

For my use case, one feature that still need some work in Timescale is their real time aggregation. It is currently impossible to define a rollup on top of another rollup, which means that if you are ingesting a lot of data into the raw table, and you down sample into a wide time bucket (e.g. a day, or week), queries against these wider buckets will potentially ended up having to query a lot of data points, slowing the system down considerably. Granted, it is a new feature that just got released about a month ago. Hopefully, with multi-node nearing completion, continuous aggregation will get a bit more love.

I spoke with their engineers about this over Slack, and their suggestion was to manually modify the rollup materialized view to aggregate over a combination of the materialized buckets (currently handled by the continuous aggregation) + real time aggregation from a higher resolution bucket.

We are still testing out Timescale, of course. But so far, it's been holding up its end of the bargain. The fact that Timescale is "just an extension" built for Postgres also makes it a less risky choice and offers a lot of flexibility; if Timescale doesn't work out, we could still work with Postgres, and that IMHO is a very nice thing.

Re: Multi-node TimescaleDB is now free

#200
post #123
post #103

Earlier quoted context omitted.

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.

But then you have put a limitation on use in production instead of sell? Commons Clause might be (too?) vague, but the concept is imho more fair to end users.

Still, I for one applaud you for this step. We need better non-OSS licenses and it's good to be having this discussion.

Post reply on HN