How TimescaleDB compresses time-series data

The useful discussion landed on the trade-off the post only partly addresses: query performance. Compression is not automatically good just because bytes on disk shrink. It pays off when the encoding also helps the engine skip work, reject segments early, or run predicates and transforms on compact representations instead of raw rows. Several comments broadened that into a general pattern for analytic storage engines: keep rich per-segment metadata like min and max values, distinct counts, or Bloom filters, then use that metadata to avoid decompressing whole chunks. Good column layout, partition pruning, filter pushdown during decompression, and aggressive parallelism often matter as much as the codec itself. A second thread tied this to industrial telemetry. Older OT historians often used lossy schemes like swinging-door compression because raw float streams were too expensive to keep. Commenters argued that modern lossless codecs like Gorilla, plus cheap disk and deduplicated storage, remove much of that pressure. The remaining caveat is operational rather than theoretical: TimescaleDB compression may not be available in distro-packaged builds because of licensing, and JSONB remains a weak spot for compression unless it is broken into typed, more columnar structures.