warn-timescale-hypertable-ddl

What It Detects

DDL on a TimescaleDB hypertable propagates to every chunk, so its cost scales with chunk count.

Why It's Dangerous

A hypertable is a facade. The data lives in chunks, each a real table, and TimescaleDB applies schema changes to the hypertable and to every one of them — so a statement that reads like one table's worth of work takes locks across the whole set and runs until the slowest chunk is done. Index creation has a specific catch: TimescaleDB does not support CREATE INDEX CONCURRENTLY on a hypertable at all, so that statement fails rather than running slowly. WITH (timescaledb.transaction_per_chunk) is the documented alternative.

Bad Example

-- metrics is a hypertable with 420 chunks
CREATE INDEX CONCURRENTLY idx_metrics_device ON metrics (device_id);
-- ERROR: CREATE INDEX CONCURRENTLY is not supported on hypertables

Good Example

-- Check the fan-out before writing the DDL: the chunk count is what
-- the statement actually costs.
SELECT hypertable_name, num_chunks, compression_enabled
FROM timescaledb_information.hypertables
WHERE hypertable_name = 'metrics';

Configuration

Disable this rule:

# .migrationpilotrc.yml
rules:
  MP105: false

Or change its severity:

# .migrationpilotrc.yml
rules:
  MP105:
    severity: warning