{"post":{"slug":"hypertables-explained-2026","title":"Hypertables: Automatic Partitioning for Time-Series Data","excerpt":"Manual time partitioning works and requires you to create next month's partition before next month arrives. Hypertables automate that, and add compression and retention on top.","category":"code","date":"January 8, 2026","author":"ByteLedger Team","content":"<span class=\"dropcap\">M</span>anual time-based partitioning is effective and has an operational tail: something must create next month's partition before data for next month arrives, or inserts fail. That job is easy to write and easy to forget, and its failure mode is a production outage at midnight on the first of the month.\n\nHypertables remove that. Partitions — called chunks — are created automatically as data arrives, and the table behaves like an ordinary table for every other purpose.\n\n## What changed in 2026\n\n- **Adoption broadened beyond metrics.** Financial data, IoT, and event logging became common use cases alongside monitoring.\n- **Compression became a standard policy.** Automatically compressing chunks older than a threshold became routine configuration.\n- **Continuous aggregates matured.** Incrementally-maintained rollups reduced the cost of dashboard queries substantially.\n- **The relational advantage held.** Keeping time-series data queryable with ordinary SQL and joinable against relational tables remained the main reason to choose this over a separate system.\n\n## What you get\n\n| | Manual partitioning | Hypertable |\n| --- | --- | --- |\n| Partition creation | You automate it | Automatic |\n| Query interface | Ordinary SQL | Ordinary SQL |\n| Retention | You script it | Policy |\n| Compression | Per-engine, manual | Policy |\n| Rollups | Materialised views you refresh | Continuous aggregates |\n| Joins to relational tables | Yes | Yes |\n\nThe last row is the real argument. Time-series data in the same database as your application data can be joined against it directly — device readings joined to device metadata, events joined to users. With a separate time-series system that requires application-level joining, which is considerably more work and slower.\n\n## Chunk interval is the decision\n\nThe main tuning parameter, and getting it wrong costs in one of two directions.\n\n**Too large** and chunks are big, so a query for a narrow time range still reads a large chunk. Pruning becomes coarse and you lose much of the benefit.\n\n**Too small** and you accumulate an enormous number of chunks. Query planning considers each one, and planning overhead grows with chunk count — the same problem as over-partitioning a relational table, per [table partitioning](/blog/table-partitioning-explained-2026).\n\nThe usual guidance targets chunks that fit comfortably in memory alongside their indexes, which in practice means intervals producing chunks of a manageable size given your ingest rate. That means the right interval depends on your data volume, not on a calendar preference — a high-ingest system wants shorter intervals than a low-ingest one for the same chunk size.\n\nGet it approximately right and adjust; the interval applies to newly-created chunks, so changing it does not rewrite history.\n\n## Compression and its cost\n\nCompressing older chunks converts them to a columnar representation, which produces large storage savings for time-series data — ordered similar values compress extremely well, per [columnar storage](/blog/columnar-storage-explained-2026).\n\nThe cost is flexibility. Compressed chunks are optimised for reading and aggregating, and modifying them is restricted or expensive depending on version and configuration. That is usually fine, because old time-series data is not updated — but it means late-arriving data for a compressed period is awkward.\n\nIf your ingest can produce records with timestamps hours or days old, set the compression threshold beyond that window. Compressing data that is still receiving late arrivals produces friction.\n\nRetention policies pair naturally: compress after a week, drop after a year. Both are metadata-level operations on whole chunks rather than row-by-row work.\n\n## Continuous aggregates\n\nThe feature that most changes dashboard performance. A continuous aggregate is a rollup — hourly averages, daily counts — maintained incrementally as new data arrives, rather than recomputed on query.\n\nA dashboard querying a year of data at hourly resolution reads a small rollup rather than scanning a year of raw records. The difference is frequently orders of magnitude.\n\nUnlike an ordinary materialised view, it updates incrementally rather than requiring a full refresh, which is what makes it practical at time-series volumes — see [what is a materialized view](/blog/what-is-a-materialized-view-2026) for the general concept.\n\n## Common mistakes\n\n- **Chunk interval chosen by calendar rather than by volume.** Produces chunks too large or too small.\n- **Compressing data still receiving late arrivals.** Awkward and expensive.\n- **No retention policy.** Storage grows without bound.\n- **Querying raw data for dashboards.** Use continuous aggregates.\n- **Using it for data without a time dimension.** The design assumes one.\n- **Ignoring chunk count.** Planning overhead grows with it.\n\n## FAQ\n\n**Is this just partitioning?**\nAutomatic partitioning plus compression, retention, and incremental rollups. The partitioning is the foundation; the policies are what remove the operational work.\n\n**Can I convert an existing table?**\nGenerally yes, with a migration that creates the hypertable and moves data. Plan for it on a large table; it is not instant.\n\n**Does it work with ordinary SQL?**\nYes — that is the main advantage. Queries, joins, and existing tooling work unchanged, which is not true of most separate time-series systems.\n\n**When would I use a dedicated time-series database instead?**\nAt very high ingest rates where a relational engine cannot keep up, or where you do not need joins to relational data and want the operational simplicity of a purpose-built system.\n\n## Where to go next\n\nFor the manual equivalent, read [table partitioning](/blog/table-partitioning-explained-2026). For the broader selection question, [time-series databases](/blog/time-series-databases-2026), and for the compression mechanism, [columnar storage](/blog/columnar-storage-explained-2026).","hue":313,"metaTitle":"Hypertables: Automatic Partitioning for Time-Series","metaDescription":"How hypertables automate time-based partitioning, why chunk interval matters, and what compressing old chunks costs in flexibility.","keywords":["hypertables","timescaledb","automatic partitioning","chunk interval","time series postgres","continuous aggregates","compression policy","database extensions 2026"],"tldr":["**Chunks are created automatically as data arrives** — no cron job creating next month's partition.","**It stays a normal table to query** — ordinary SQL, ordinary joins, ordinary tooling.","**Chunk interval is the main tuning decision** — too large loses pruning, too small adds planning overhead.","**Compression converts old chunks to columnar form** — large storage savings, at the cost of update flexibility.","**Skip:** hypertables for data without a time dimension. The whole design assumes one."],"readTime":"4 min read","wordCount":891},"related":[{"slug":"table-partitioning-explained-2026","title":"Table Partitioning: Splitting One Table Without Sharding","excerpt":"Partitioning divides a table into pieces inside one database. It is not sharding, it is not a general speed-up, and it solves a narrower problem than most people expect.","category":"code","date":"August 12, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":310},{"slug":"time-series-databases-2026","title":"Time-Series Databases: When a Normal Table Stops Coping","excerpt":"Metrics, events, and sensor readings share a shape ordinary databases handle badly at volume. Purpose-built stores exploit that shape, and a partitioned relational table gets you most of the way.","category":"code","date":"January 13, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":318},{"slug":"database-indexing-explained-2026","title":"Database indexing explained in 2026: what every developer must know","excerpt":"Bad indexes cause more production incidents than almost any other root cause. Here is the 2026 guide to choosing, building, and maintaining the right ones.","category":"code","date":"March 10, 2026","author":"ByteLedger Team","readTime":"5 min read","hue":318}],"sameCategory":[{"slug":"bazel-build-explained-2026","title":"Bazel Explained: What Hermetic Builds Actually Cost","excerpt":"Bazel delivers reproducible, precisely cached builds and demands that you describe everything. Here is what you get, what it costs, and who should say no.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":145},{"slug":"graphql-federation-2026","title":"GraphQL Federation: One Graph, Many Teams","excerpt":"Federation composes independently-owned subgraphs into a single API. Here is what it solves, the operational cost it adds, and when a simpler gateway is enough.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":300},{"slug":"hermetic-builds-explained-2026","title":"Hermetic Builds Explained: Same Inputs, Same Output","excerpt":"A hermetic build depends only on declared inputs. Here is what that property gives you, the common leaks that break it, and how to move toward it incrementally.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":130},{"slug":"monorepo-tooling-compared-2026","title":"Monorepo Tooling Compared: What You Actually Need","excerpt":"Monorepo tools solve task orchestration and caching, not repository layout. Here is what each tier provides and how to tell when you have outgrown the simple option.","category":"code","date":"August 19, 2026","author":"ByteLedger Team","readTime":"3 min read","hue":150}],"newer":{"slug":"eval-contamination-explained-2026","title":"Eval Contamination: When the Test Was in the Training Data","excerpt":"A model scoring well on a public benchmark may have seen it. Contamination inflates results silently, and it is why a strong published score should raise suspicion rather than confidence.","category":"ai","date":"January 8, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":220},"older":{"slug":"kvm-switch-guide-2026","title":"KVM Switches: One Keyboard and Screen, Several Machines","excerpt":"Running two computers at one desk means either two sets of peripherals or a switch. The switch is usually right, and the specifications that matter are not the ones on the box.","category":"tech","date":"January 8, 2026","author":"ByteLedger Team","readTime":"4 min read","hue":245}}