Live data from Hacker News

An update to the Timescale license

blog.timescale.com

31–40 of 210 posts

Re: An update to the Timescale license

#31
post #24
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!

I'm using TimescaleDB for algo trading and it is performing beautifully. It's been rock solid and is handling everything being thrown at it (and in my case, it's every second of every day, yes weekends too).

edit: I have about 24,000 tables most with millions of rows. All 24,000 tables are touched at least daily. Often every few seconds.

Re: An update to the Timescale license

#32
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?

Azure Postgres offers the Apache-2 Edition of TimescaleDB, not the Community Edition (which the TSL applies to). Same with DigitalOcean, Rackspace, Scaleways, Alibaba, etc.

So they can continue to offer the Apache-2 Edition, but could not before, and still can't, offer the Community Edition.

Community is where a lot of our more advanced features lie: multi-node, columnar compression, continuous and real-time aggregates, automation, advanced analytics, etc.

Re: An update to the Timescale license

#33
post #19

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

This is all great to hear, and the whole team really loves this type of feedback/support from the community.

So thank YOU!

(Feel free to also reach out to me at mike (at) timescale anytime, or mike in slack.timescale.com)

Re: An update to the Timescale license

#34
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…

> No right to distribute modified Source

Still seems like a serious issue to me.

Re: An update to the Timescale license

#38
I'm developing a bit of a Pavlovian response to blog posts that begin with "An update to ", so I was glad to see that all of the changes seem really positive.

TimescaleDB is a neat piece of software and I'd definitely recommend checking it out if you're looking for a time series database. I had used some of their competitors in the past and it wasn't a fun experience. They had a high learning curve (things like multiple custom query languages, quasi-relational design that led to massive performance penalties if used the "wrong" way, etc), and at least for my use case the performance wasn't even good enough to justify the esotericism (although I've only used Timescale on small hobby projects with low data rates so maybe it's not fair to complain about another DB's performance with heavier workloads).

IMO what makes Timescale so great and user friendly is that after you set up your tables you can treat it like a regular old SQL database. Everything just works, and you get all the niceties when you make temporal queries.

Re: An update to the Timescale license

#39

Is there a list of enterprise features which are now free?

Most of the enterprise features were moved actually moved into the Community tier in our 1.7 release, where we also announced that the upcoming multi-node would also be a Community feature:

https://blog.timescale.com/blog/timescaledb-1-7-fast-continu...

(Many thought that multi-node would be an enterprise feature, as that's somewhat common for databases.)

I believe that it was only data-tiering that was remaining/moved from enterprise to community as part of the 2.0 release. But the bigger thing is the "elimination" of the notion of enterprise / usage limits from the license and code base, as a statement for the future.

Re: An update to the Timescale license

#40
post #25

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

Another side question, please.

How does TimescaleDB compare to Clickhouse? Since you mentioned compression, I've been using Clickhouse to store bitemporal data, and have been amazed by its speed and compression levels. Unfortunately it's lacking in terms of relational modeling.

Would I get the best of two worlds with TimescaleDB? What are the tradeoffs?

Post reply on HN