TimescaleDB confuses me. Postgres is an OLTP database and their disk storage format is uncompressed and not particularly effective.

By clever sharding, you can work around the performance issues somewhat but it'll never be as efficient as an OLAP column store like ClickHouse or MemSQL:

- Timestamps and metric values compress very nicely using delta-of-delta encoding.

- Compression dramatically improves scan performance.

- Aligning data by columns means much faster aggregation. A typical time series query does min/max/avg aggregations by timestamp. You can load data straight from disk into memory, use SSE/AVX instructions and only the small subset of data you aggregate on will have to be read from disk.

So what's the use case for TimescaleDB? Complex queries that OLAP databases can't handle? Small amounts of metrics where storage cost is irrelevant, but PostgreSQL compatibility matters?

Storing time series data in TimescaleDB takes at least 10x (if not more) space compared to, say, ClickHouse or the Prometheus TSDB.

(TimescaleDB co-founder)

TimescaleDB is more performant that you may think. We've benchmarked this extensively: eg outperforming vs InfluxDB [1] [2], vs Cassandra [3], vs Mongo [4].

We've also open-sourced the benchmarking suite so others can run these themselves and verify our results. [5]

We also beat MemSQL regularly for enterprise engagements (unfortunately can't share those results publicly).

I think the scalability of ClickHouse is quite compelling, and if you need more than 1-2M inserts a second and 100TBs of storage, then that would be one reason where I'd recommend another database over our own. But horizontal scalability is something we have been working on for nearly a year, so we expect this to be a less of an issue in the near future (will have more to share later this month).

You are correct however that TimescaleDB requires more storage than some of these other options. If storage is the most important criteria for you (ie more important than usability or performance), then again I would recommend you to one of the other databases that are more optimized for compression. However, you can get 6-8x compression by running TimescaleDB on ZFS today, and we are also currently working on additional techniques for achieving higher compression rates.

[1] https://blog.timescale.com/timescaledb-vs-influxdb-for-time-...

[2] https://blog.timescale.com/what-is-high-cardinality-how-do-t...

[3] https://blog.timescale.com/time-series-data-cassandra-vs-tim...

[4] https://blog.timescale.com/how-to-store-time-series-data-mon...

[5] https://github.com/timescale/tsbs