Every time TimescaleDB is brought up, I feel the need to point people to their shadily worded proprietary licence[0], and pg_partman[1].<p>Do the same benchmarks against a pg_partman managed partitioned db and you'll get the exact same performance. We do, at least - 150k or so metrics per second, 10 columns per metric.<p>Not trying to crap on the TimescaleDB guys, I've found a lot of their writeups extremely useful and can totally see how their commercially supported product fits. However, I like to see pg_partman at least mentioned somewhere in the article/comments. It's awesome and does the same job.<p>[0]<a href="https://github.com/timescale/timescaledb/blob/master/LICENSE" rel="nofollow">https://github.com/timescale/timescaledb/blob/master/LICENSE</a><p>[1]<a href="https://github.com/pgpartman/pg_partman" rel="nofollow">https://github.com/pgpartman/pg_partman</a>
TimescaleDB confuses me. Postgres is an OLTP database and their disk storage format is uncompressed and not particularly effective.<p>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:<p>- Timestamps and metric values compress very nicely using delta-of-delta encoding.<p>- Compression dramatically improves scan performance.<p>- 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.<p>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?<p>Storing time series data in TimescaleDB takes at least 10x (if not more) space compared to, say, ClickHouse or the Prometheus TSDB.
Experiences with Zabbix? I tried it back around a decade ago and wanted to like it, but didn't find it very reliable. And now the details are escaping me. I ended up sticking with Nagios and Opsview. Around 5 years ago I switched to a templated Icinga2 config and have been pretty happy with that, but it's pretty low level.
The biggest problem I've had with timescale systems is managing the SSDs/HDDs underneath.<p>Having to resize/grow/stripe/etc. them is a pain.<p>So we came up with a clever solution that batches chunks to S3:<p><a href="https://www.youtube.com/watch?v=x_WqBuEA7s8" rel="nofollow">https://www.youtube.com/watch?v=x_WqBuEA7s8</a><p>$10/day for 100M records (100GB data), all costs!<p>And best yet, reduced DevOps! Very practical, super simple.