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