TimescaleDB Compression: Hypercore and Columnar Storage with up to 98% Ratio in PostgreSQLSkip to main content<br>Aleksander Roszig<br>May 29, 2026 | 12 min ReadTimescaleDB Compression: Hypercore and Columnar Storage with up to 98% Ratio in PostgreSQL<br>TimescaleDB can achieve compression of up to 98% for typical time-series data. Compressing time-series data requires a fundamentally different approach than the general-purpose algorithms used in OLTP databases. In TimescaleDB this is handled by the hypercore engine — a hybrid row-columnar engine that uses specialized algorithms: delta encoding, delta-of-delta, Gorilla XOR and run-length encoding. This article explains how it works and how to configure compression so that you actually achieve that ratio.<br>TimescaleDB compression - how it differs from PostgreSQL TOAST<br>PostgreSQL has a built-in mechanism called TOAST (The Oversized-Attribute Storage Technique), but TimescaleDB compression solves a fundamentally different problem. TOAST deals with individual large values (long strings, jsonb, bytea), whereas TimescaleDB compression optimizes cross-row patterns in time-series data. The two mechanisms are complementary, not competing — TimescaleDB even uses TOAST internally as a fallback for certain data types.<br>PostgreSQL uses a fixed &ldquo;page size&rdquo;, typically 8 kB, and does not allow tuples to span multiple pages. For that reason, when field values are very large, the data must be compressed and/or split across multiple physical rows.<br>FeatureTOAST (vanilla PostgreSQL)TimescaleDB hypercoreDesign goalIndividual values > 2 KBCross-row patterns in time-seriesTriggerRow exceeds TOAST_TUPLE_THRESHOLD (~2 KB)Per-chunk policy (e.g. older than 7 days)Supported typesVariable-length only (text, jsonb, bytea, numeric)All data typesAlgorithmspglz (default), lz4 (since PG14, opt-in)Combination: delta encoding, delta-of-delta, simple-8b, run-length encoding, XOR-based, dictionary compressionCompression granularityPer value (1 value = 1 byte stream)Per batch (~1000 rows together)Exploiting data structureNo - treats values as opaque bytesYes - exploits numeric structure, monotonicity, repetitionTypical ratio for sensor floats~1.0× (no compression)10-20×Typical ratio for timestamps~1.0× (no compression - fixed-length type)50-100× (delta-of-delta for regular intervals)Typical ratio for text2-3× (general-purpose LZ)5-10× (dictionary + RLE if repetitive)<br>The table shows the scale of the difference. For a typical IoT workload with floats and timestamps — i.e. the columns TOAST does not compress at all — TimescaleDB reaches a ratio of 10-100×, because it is built for this type of data.<br>The Hypercore engine and columnar compression<br>In TimescaleDB, compression is handled by an engine called hypercore — a hybrid row-columnar engine in which new data lands in Postgres row-based chunks (fast INSERTs and UPDATEs), while older chunks are automatically converted to a columnar, compressed format. Analytical queries that read this compressed data read fewer bytes and run faster. This conversion enables compression of up to 98%, which significantly lowers storage costs in projects with long data retention. Unlike traditional row-based storage, where data is stored sequentially by row, columnar storage organizes and compresses data by column. As a result, queries can fetch only the necessary fields in batches instead of scanning entire rows.<br>What happens to the rows<br>Converting a chunk groups rows into batches of up to 1000 and each batch becomes a single row in the compressed table , in which the columns are arrays.<br>Each compressed batch:<br>Encapsulates columnar data in compressed arrays of up to 1000 values per column, stored as a single entry in the compressed table.<br>Uses a column-major format inside the batch, which enables efficient scans by colocating values of the same column and lets you select individual columns without reading the entire batch.<br>Applies advanced column-level compression techniques — run-length encoding, delta encoding, Gorilla compression — reducing storage and improving I/O.<br>Source: https://www.tigerdata.com/docs/learn/deep-dive/whitepaper#data-model<br>An example of compression using delta encoding:<br>timemachine_idsensor_typevalue12:00:00MACHINE_001temp72.512:00:00MACHINE_001speed2.012:00:05MACHINE_001temp72.712:00:05MACHINE_001speed2.112:00:10MACHINE_001temp72.412:00:10MACHINE_001speed2.4<br>With delta encoding you only need to store how much each value changed relative to the previous data point, which means smaller values to store. After the first row, you can represent the following rows using less information, for example:<br>timemachine_idsensor_typevalue12:00:00MACHINE_001temp72.50 secondsMACHINE_001speed2.05 secondsMACHINE_001temp+0.20 secondsMACHINE_001speed+0.15 secondsMACHINE_001temp-0.30 secondsMACHINE_001speed+0.3<br>In time-series data it is often the case that certain values repeat for some period. For example, if you have a temperature sensor that reads 72.5 degrees...