Live data from Hacker News

Multi-node TimescaleDB is now free

blog.timescale.com

211–220 of 220 posts

Re: Multi-node TimescaleDB is now free

#211
post #4

This is an interesting window into their business model. This could be a purely an altruistic decision, which businesses sometimes do, contrary to popular belief. More likely it's a bet that wider adoption from making the clustered version free will drive more revenue through their managed database as a service offering. Which shows that their non-OSI open-source license is actually leading to more code and features…

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

> AWS and other cloud vendors are taking advantage, but that is not a good reason to give up on the ideals of the movement.

Why not?

Re: Multi-node TimescaleDB is now free

#212
post #209

Earlier quoted context omitted.

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.

I appreciate the discussion here, and as mentioned elsewhere, this has been good motivation for us to revisit this clause in the Timescale License, as a bit has changed since we released it in 2018. That said, I think a lot of this discussion misattributes the frequency of behaviors. For example, I bet the percentage of organizations that modify the source code of open-source databases like MySQL or Postgres before u…

I agree with the thoughts on discussion and appreciate that you are taking the time to answer this thread!

Just to clarify: while the percentage of those who exercise this particular freedom (modifying the source and then using it in production) is probably very very small, it is an important freedom to have for a much bigger part of customers. It is an insurance policy that gives users confidence that Timescale Corp will not become user hostile - or if it does, it is still possible to make critical security fixes until a more permanent solution is found.

But I do understand it is difficult to find a solution that would please everyone. I am very curious if you will manage to find a more generic solution to this problem. :) Good luck!

Re: Multi-node TimescaleDB is now free

#213

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

If you use PostgreSQL, then it feels natural to add TimescaleDB extension and start storing time series or analytical data there alongside other relational data. If you need effectively storing trillions of rows and performing real-time OLAP queries over billions of rows, then it is better to use ClickHouse [1], since it requires 10x-100x less compute resources (mostly CPU, disk IO and storage space) than PostgreSQL…

It is customary on HN to disclaim when you are a member of/contributor to products you are suggesting.

Re: Multi-node TimescaleDB is now free

#214
post #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.

I remember being very impressed with numbers from the following tweet https://twitter.com/this_is_tckb/status/1256649880434606080.

I'm wondering what is the cost of your setup to handle billions of timeseries?

Re: Multi-node TimescaleDB is now free

#215

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

If you use PostgreSQL, then it feels natural to add TimescaleDB extension and start storing time series or analytical data there alongside other relational data. If you need effectively storing trillions of rows and performing real-time OLAP queries over billions of rows, then it is better to use ClickHouse [1], since it requires 10x-100x less compute resources (mostly CPU, disk IO and storage space) than PostgreSQL…

We spent about 6 months looking at pretty much every database tech on the market, cockroach, clickhouse, influx, voltdb, memsql etc were top contenders, there was an outdated article on medium.com (by victoria metrics) which slammed TimescaleDB for its disk usage, we did not realised it was biased, so we dropped TSDB dropped off the list, but we saw a email about their compression segment by device_id, and gave it a shot, ....we implemented it, 5 months after our production release we now have outstanding performance and compression (95x) We are planning to move the rest of our databases to TSDB now as it ticks our boxes our use case is HTAP, not solely OLAP and OLTP

I'm super excited about this news, but TSDB please work on allowing us to put data over 1 year old on slow disk seperate servers, so we can keep the hot stuff on the NVME servers, once you get this sorted it will be the perfect fit for us.

Re: Multi-node TimescaleDB is now free

#216

Earlier quoted context omitted.

If you use PostgreSQL, then it feels natural to add TimescaleDB extension and start storing time series or analytical data there alongside other relational data. If you need effectively storing trillions of rows and performing real-time OLAP queries over billions of rows, then it is better to use ClickHouse [1], since it requires 10x-100x less compute resources (mostly CPU, disk IO and storage space) than PostgreSQL…

We spent about 6 months looking at pretty much every database tech on the market, cockroach, clickhouse, influx, voltdb, memsql etc were top contenders, there was an outdated article on medium.com (by victoria metrics) which slammed TimescaleDB for its disk usage, we did not realised it was biased, so we dropped TSDB dropped off the list, but we saw a email about their compression segment by device_id, and gave it a…

Glad to hear it is working out for you! I'll relay the request re: old data. But please also feel free to email me directly at ajay (at) timescale.com (or email support (at) timescale.com) if you have any follow up questions / requests.

Re: Multi-node TimescaleDB is now free

#217

Earlier quoted context omitted.

If you use PostgreSQL, then it feels natural to add TimescaleDB extension and start storing time series or analytical data there alongside other relational data. If you need effectively storing trillions of rows and performing real-time OLAP queries over billions of rows, then it is better to use ClickHouse [1], since it requires 10x-100x less compute resources (mostly CPU, disk IO and storage space) than PostgreSQL…

We spent about 6 months looking at pretty much every database tech on the market, cockroach, clickhouse, influx, voltdb, memsql etc were top contenders, there was an outdated article on medium.com (by victoria metrics) which slammed TimescaleDB for its disk usage, we did not realised it was biased, so we dropped TSDB dropped off the list, but we saw a email about their compression segment by device_id, and gave it a…

> TSDB please work on allowing us to put data over 1 year old on slow disk seperate servers, so we can keep the hot stuff on the NVME servers, once you get this sorted it will be the perfect fit for us.

ClickHouse recently added multi-volume storage for exactly the use case you describe. [1] It's a great feature.

[1] https://www.altinity.com/blog/2019/11/27/amplifying-clickhou...

Re: Multi-node TimescaleDB is now free

#218

Earlier quoted context omitted.

We spent about 6 months looking at pretty much every database tech on the market, cockroach, clickhouse, influx, voltdb, memsql etc were top contenders, there was an outdated article on medium.com (by victoria metrics) which slammed TimescaleDB for its disk usage, we did not realised it was biased, so we dropped TSDB dropped off the list, but we saw a email about their compression segment by device_id, and gave it a…

Glad to hear it is working out for you! I'll relay the request re: old data. But please also feel free to email me directly at ajay (at) timescale.com (or email support (at) timescale.com) if you have any follow up questions / requests.

Good news: TimescaleDB already offers this feature. Feel free to ping us support (at) timescale.com and we can walk you through it. Thanks!

Re: Multi-node TimescaleDB is now free

#219

Earlier quoted context omitted.

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 Val…

If I'm reading https://github.com/timescale/timescaledb/blob/master/tsl/LIC... right, then for a SaaS company -- not necessarily a database-as-a-service company -- section 3.11 states that SaaS company can't run Data Definition Language (DDL) commands like CREATE, DROP, ALTER, TRUNCATE, COMMENT, and RENAME.

So if I need to adjust my schema using ALTER TABLE, how would I do that and stay license compliant?

Or if I'm running out of disk and need to run DROP TABLE, is my only choice to simply get more disk space rather than dropping tables?

Some of our customers will need their own unique schema, and will need their own tables. So, how would we even run CREATE TABLE and stay compliant?

Maybe I'm missing something?

Re: Multi-node TimescaleDB is now free

#220

Hi, I authored this post, but the credit really goes to the Timescale database team. Multi-node TimescaleDB is the result of a massive amount of engineering effort over two years, as can be seen in this +67,000 line PR: https://github.com/timescale/timescaledb/pull/1923 We're thrilled to make this free so that more developers can use it.

Definitely excited as well!

Curious how we buy support?

Looking at https://www.timescale.com/support there doesn't seem to be any support plan for on-prem TimescaleDB.

Post reply on HN