English for TimescaleDB

TimescaleDB looks and behaves like ordinary Postgres on the surface, which is exactly why its specific vocabulary — hypertable, chunk, continuous aggregate — matters: without naming these precisely, a performance conversation quietly turns into generic Postgres tuning advice that misses the time-series-specific cause.

Key Vocabulary

Hypertable — TimescaleDB’s abstraction over a regular Postgres table that automatically partitions data by time (and optionally another dimension) into smaller physical tables, while still being queried as a single logical table. “We converted the metrics table into a hypertable partitioned by day — queries still look like plain SQL against one table, but under the hood Timescale is only scanning the relevant time-based partitions.”

Chunk — the individual physical table that makes up one time partition within a hypertable, created automatically as new data arrives outside the range of existing chunks. “The slow query was scanning far more chunks than it needed to, because the query didn’t include a time filter Timescale could use to prune irrelevant partitions.”

Continuous aggregate — a materialized view that TimescaleDB keeps incrementally up to date as new data arrives, used to pre-compute rollups (like hourly averages) without re-scanning raw data on every query. “Instead of aggregating a year of raw readings on every dashboard load, we query a continuous aggregate that’s already rolled up to hourly averages and refreshes incrementally.”

Compression policy — an automated rule that compresses chunks older than a specified age, dramatically reducing storage for historical data that’s queried less frequently and rarely updated. “We added a compression policy for chunks older than 7 days, which cut storage costs substantially since most queries only touch the most recent week anyway.”

Retention policy — an automated rule that drops chunks older than a specified age entirely, used when historical data beyond a certain point no longer needs to be queryable at all. “We set a 90-day retention policy on the raw event table since we only need aggregate trends beyond that window, not the individual raw events.”

Common Phrases

• “Is this table actually a hypertable, or is it still a plain Postgres table that just happens to store time-series data?”
• “Is the query slow because it’s scanning too many chunks, or is there a missing index within each chunk?”
• “Should this rollup be a continuous aggregate, or are we recomputing it from raw data on every request?”
• “Is a compression policy applied to older chunks here, or is all of this data still stored uncompressed?”
• “Does this data need a retention policy, or should it be kept indefinitely?”

Example Sentences

Diagnosing a slow query: “The dashboard query was scanning a full year of chunks even though it only needed the last 24 hours — adding an explicit time-range filter let Timescale prune almost all of those chunks.”

Explaining a cost optimization: “We added a compression policy on chunks older than two weeks, which reduced storage costs significantly with no impact on the recent-data queries the dashboard actually relies on.”

Describing a design decision in a review: “We built this as a continuous aggregate instead of a plain materialized view, since Timescale refreshes it incrementally as new data arrives, rather than requiring a full recompute on a schedule.”

Professional Tips

• Say hypertable explicitly when discussing whether time-series data is properly set up — “it’s a Postgres table” glosses over the distinction that actually matters for partitioning and pruning.
• Name chunk pruning when explaining a slow time-series query — a missing time filter, not a missing index, is the most common root cause.
• Use continuous aggregate precisely, not interchangeably with “materialized view” — the incremental refresh behavior is the specific feature worth calling out.
• Distinguish compression from retention clearly in cost discussions — one shrinks storage while keeping data queryable, the other deletes it entirely, and conflating them risks losing data unintentionally.

Practice Exercise

1. Explain what a hypertable is and how it differs from a regular Postgres table.
2. Describe why an unfiltered time-range query can scan far more chunks than necessary.
3. Write a sentence explaining the difference between a compression policy and a retention policy.