TimescaleDB — Time-Series Tables
Hypertables, continuous aggregates, compression. MonPG reads chunk health if installed.
TimescaleDB is application-side. When it's installed, MonPG's Schema Statistics page surfaces hypertable-specific information: the hypertable list with chunk counts and total compressed/uncompressed sizes, continuous aggregate refresh policies and last-refresh lag, retention policy lag (chunks older than the policy that haven't been dropped), and per-hypertable compression ratios.
The most useful of these in practice is the retention lag. It's the silent failure mode — your retention policy says "drop chunks older than 90 days" but the background worker has been off for two weeks and chunks are piling up. The lag metric tells you immediately.
Where it's available
| Provider | Edition |
|---|---|
| AWS RDS | Apache (community) only. No compression, no continuous aggregates. For TSL features go to Timescale Cloud. |
| Azure Flex | Apache + TSL via Azure-managed extension. Blocks in-place major version upgrades, which is worth knowing in advance. |
| Cloud SQL | Not available. |
| Crunchy / Aiven | Apache. |
| Self-hosted | Both editions, your choice. |
What MonPG flags
Three patterns that come up a lot. Compression backlog — chunks past the compression threshold but still uncompressed. Schedule a one-shot compression job; the background worker should be doing this but sometimes isn't. CAGG refresh lag — a continuous aggregate that hasn't refreshed in more than the bucket interval × 2; usually a busted refresh policy or a worker pool too small to keep up. Chunk explosion — a hypertable with more than 10k chunks almost always means chunk_time_interval is too small for the data rate. The fix is recreating with a larger interval, which is annoying enough that people ignore the warning until they can't.