Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An update to the Timescale license

blog.timescale.com

Post reply on HN
Print view View original

21–30 of 210 posts

Re: An update to the Timescale license

#21

Post by eloff »

btown wrote: post #12
sytse wrote: post #6

Earlier quoted context omitted.

This is certainly a great improvement in the license! Kudos to TimescaleDB. I wonder if the new license allows us to offer services on top of TimescaleDB in a multi-tenant setting. GitLab.com has metric monitoring https://docs.gitlab.com/ee/operations/metrics/ and we're considering using TimescaleDB to store these. We would not offer direct access to the database. The relevant section in the license https://www.times…

Also not a lawyer but it appears the bar is that "(2) the 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." For Timescale this may not be as relevant, but I do…

I would guess that jsonb columns or Entity-Attribute-Value type of schemas are permitted, but if doing something in a grey area it wouldn't hurt to reach out to the company and get permission in writing (or negotiate a license exception.)

Or just pay for their managed service, you probably don't want to be fiddling around with hosting the database yourself. At least everywhere I've worked we used RDS for precisely that reason.

Re: An update to the Timescale license

#22

Post by mfreed »

btown wrote: post #12
sytse wrote: post #6

Earlier quoted context omitted.

This is certainly a great improvement in the license! Kudos to TimescaleDB. I wonder if the new license allows us to offer services on top of TimescaleDB in a multi-tenant setting. GitLab.com has metric monitoring https://docs.gitlab.com/ee/operations/metrics/ and we're considering using TimescaleDB to store these. We would not offer direct access to the database. The relevant section in the license https://www.times…

Also not a lawyer but it appears the bar is that "(2) the 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." For Timescale this may not be as relevant, but I do…

Storing JSON or EAV-format data do not require DDL access, and are commonly deployed in many settings, from product/SaaS analytics, IoT, IT/APM monitoring, and others.

That's actually one of the reasons we tried to frame it in terms of interfaces as well.

(Thanks for the question/interest!)

Re: An update to the Timescale license

#23

Post by snarkypixel »

A bit of a side question, but how slow would it be if we were to query the data without using a time-based approach? I.e. "select * from obj where parent_id = " --> Imagine we had billions of obj and a few thousands matching "parent_id" added randomly during the last 5-10 years. Would there be an index on "parent_id" or would it need to read every hypertable for such a query?

Basically, I'm trying to understand if Timescale is /only/ useful for timeseries or if it has good-enough performance for other use-cases.

Re: An update to the Timescale license

#24

Post by nmaludy »

ttsda wrote: post #19

I've been following these guys since the project started, and it keeps getting better! Well done!

Agreed!

We run several instances in production and have had zero problems. TimescaleDB engineers, if you are watching / reading. Thank you VERY MUCH! You totally rock!

Re: An update to the Timescale license

#25

Post by mfreed »

snarkypixel wrote: post #23

A bit of a side question, but how slow would it be if we were to query the data without using a time-based approach? I.e. "select * from obj where parent_id = " --> Imagine we had billions of obj and a few thousands matching "parent_id" added randomly during the last 5-10 years. Would there be an index on "parent_id" or would it need to read every hypertable for such a query? Basically, I'm trying to understand if Ti…

Internally, a hypertable "partitions" data into 1+ dimensions, typically always by time, but also by other dimensions (esp. for multi-node). Each of these partitions are called a "chunk" (and are actually Postgres tables within the DB).

You can also define arbitrary indexes on a hypertable; practically, these index definitions get "pushed down" to all chunks, so an index is built on each chunk.

Queries have two-stages:

1. Using "constraint exclusion" by looking at the SQL query and constaints on each chunk (e.g., their time interval), exclude certain chunks for the query.

2. "Push down" the query (often in parallel) to all non-excluded chunks, and collect/aggregate those results.

Various features in TimescaleDB will help even in your case:

1. You get parallelism to scan across chunks. If employing multi-node (TimescaleDB 2.x), you can parallelize these aggregations across servers.

2. You can employ native columnar compression, which gets like 94-97% compression rates, and allows you to organize your data based on selected keys (the "segmentby" parameter). So if you "segmentby" parent_id, it really collocates that data together, and enables much faster query.

Thanks for quesiton!

https://docs.timescale.com/

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

https://slack.timescale.com//

Re: An update to the Timescale license

#26

Post by EvanAnderson »

GordonS wrote: post #15
slashdev wrote: post #2

It would seem these folks listened to the criticism of their Timescale License here on HN and took it to heart. Right to repair, right to improve, and the gating of enterprise features were the only serious criticisms, and they've been addressed. I tip my metaphorical hat to them. I'm curious to see if some vocal people here will still not be satisfied with anything short of a OSI-approved FOSS license. Really the on…

Yep, they even quoted some recent HN comments in the article. I have absolutely no doubt that a small but vocal minority will remain unsatisfied. I'm not surprised by this move, as there was barely anything left in the Enterprise license anyway. Personally, I think this is a great move, and one that should in theory leave that vocal minority with very little to actually grumble about.

I likely qualify as "vocal minority". These changes make TimescaleDB something I could entertain using.

My concerns related to the "right-to-repair" / "right-to-improve", and with vendor lock-in. These changes address my concerns handily.

Re: An update to the Timescale license

#27

Post by hodgesrm »

nemothekid wrote: post #10

While this looks like the end of arbitrary enterprise tiers, when I look around to me it looks like the other database providers saw Snowflake execute "cloud" brilliantly, and now everyone is trying to emulate that. Turns out the need to keep your data on prem has been greatly exaggerated, and most companies would rather pay a single cloud bill than paying for more machines and FTEs to handle another product.

> Turns out the need to keep your data on prem has been greatly exaggerated...

It's more like selling on-prem is slower and can lead to a slower growth ramp. The change may reflect pressure to focus on growth to ensure payback on investment. If you execute like Snowflake it accelerates revenue growth significantly.

Re: An update to the Timescale license

#29

Post by k-rus »

jordz wrote: post #28

Hey! Maybe mfreed could answer this but how does this affect users of Timescale as part of Azure's Managed Posgres service, is this something that will still continue to be available?

It is Apache version of TimescaleDB there (right?), which stays the same. While, those, who are using TimescaleDB under Timescale license, e.g., on premise, have now right to repair, for example.
Post reply on HN