3 ms·
Compression and aggregation performance in TimescaleDB is much worse than ClickHouse - it represents a different tradeoff, you trade relational features for raw
by lima 6y ago
Compression and aggregation performance in TimescaleDB is much worse than ClickHouse - it represents a different tradeoff, you trade relational features for raw speed.
TimescaleDB is basically (very) fancy PostgreSQL sharding and row-oriented, while ClickHouse is a column store.
Depending on what you need to do, ClickHouse dictionaries and JOINs might be good enough.
- akulkarni 6y ago> Compression and aggregation performance in TimescaleDB is much worse than ClickHouse You are likely basing this off on an old version of TimescaleDB. For the last year TimescaleDB has included native compression (in part by storing data in a columnar format): https://blog.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/ https://blog.timescale.com/blog/building-columnar-compressio... TimescaleDB now implements delta-delta, Gorilla, and other best-in-class compression algorithms: https://blog.timescale.com/blog/time-series-compression-algorithms-explained/ https://blog.timescale.com/blog/time-series-compression-algo... This has yielded 94%+ compression, which should make TimescaleDB and Clickhouse fairly similar in storage compression.
- ants_a 6y agoThere is no technical tradeoff here. PostgreSQL could add a batched, vectorized and JITed execution engine, and ClickHouse could add "relational features". Either one would of course be a significant engineering project, but there is no fundamental breakthrough required. A small matter of programming as they say.