[mfreed]

Hi - I just want to clarify some mistake / misrepresentation about our Timescale License (TSL):

1. The TSL is not a new license, have had it in place since late 2018. What we recently announced is that multi-node TimescaleDB will be available for free under the TSL (free, source available), while (for example) clustered InfluxDB is purely proprietary (paid, closed source).

2. Our TSL license prevents offering TimescaleDB-as-a-service, it absolutely does NOT prevent you from running/offering a SaaS service or from utilizing cloud services/infra (you say "it is locking you down to your own infrastructure unless you want to pay for timescale own SAAS offering"). Specifically, Timescale offers a pure Apache-2 version and a "Timescale License" (TSL) Community version. For the TSL version, what it primarily restricts is the cloud providers like AWS and Azure from offering TimescaleDB-as-a-service (e.g., TimescaleDB Community on AWS RDS). Many thousands of companies use our community version for free to build SaaS services running on their own AWS instances.

[1996]

> InfluxDB is purely proprietary (paid, closed source).

And clickhouse is not. I just suggest skipping the timescaledb step to someone migrating from influx, and going straight to clickhouse.

> For the TSL version, what it primarily restricts is the cloud providers like AWS and Azure from offering TimescaleDB-as-a-service (e.g., TimescaleDB Community on AWS RDS)

If there is some kind of emergency and I need to have the database on the cloud, this is a serious restriction. It limits my choices and constrains my actions.

> Many thousands of companies use our community version for free to build SaaS services running on their own AWS instances.

We have our servers, so it wasn't an issue. It was more of a long term concern, a chilling effect: what else may be restricted in the future?

Again, I think timescaledb has a wonderful place. It will certainly become the entry level database for timeseries.

It is just not suite for our workload.

[mfreed]

Hey, thanks for the continued discussion:

  > If there is some kind of emergency and I need to have
  > the database on the cloud, this is a serious restriction.
  > It limits my choices and constrains my actions.

  > if the license change to allow me to deploy to a cluster
  > of AWS servers (just in case we ditch our own hardawre),

You can deploy TimescaleDB on AWS servers (the TSL certainly allows it). Most of our users do. They don't run their own hardware.

You can even use our Apache-2 k8s helm charts [1] to immediately spin up a cluster of replicated TimescaleDB nodes with automated leader-election/failover and continuous incremental backup. The helm charts have first-class support for AWS EKS.

What the TSL prevents is _Amazon_ offering TimescaleDB as a paid DBaaS service. To my knowledge, none of the major cloud vendors offer Clickhouse as a first-class paid service, so that's somewhat a moot point. I guess theoretically Amazon could launch Clickhouse-as-a-service, but that theoretical possibility doesn't help you in your emergency.

[1] https://github.com/timescale/timescaledb-kubernetes

[fiddlerwoaroof]

Apart from license issues, Clickhouse is just really impressive: it’s a minor pain operationally, but in our tests it left all the Postgres-based timeseries solutions in the dust for real-time analytics without rollup tables.

[1996]

> Clickhouse is just really impressive: it’s a minor pain operationally, but in our tests it left all the Postgres-based timeseries solutions in the dust for real-time analytics without rollup tables

There are many things I'm willing to tolerate with that level of performance!