Understanding TimescaleDB Background Workers and Jobs

TimescaleDB's automation is one of its best features. Compression, retention, continuous aggregate refreshes -- all handled by scheduled jobs running in the background. But there is a hidden scaling cliff that most teams hit without warning: the background worker pool has a hard ceiling, and when your jobs outgrow it, everything breaks silently. No errors. No alerts. Just stale aggregates, uncompressed chunks piling up, and retention policies that stopped firing days ago. The Mechanics of Background Workers Every time you call add_compression_policy() , add_retention_policy() , or add_continuous_aggregate_policy() , TimescaleDB registers a scheduled job. Each job runs in a PostgreSQL background worker -- an independent process that executes outside of any client connection. The number of available background workers is controlled by two settings: timescaledb.max_background_workers -- the ceiling for TimescaleDB's own scheduler (default: 8-16) max_worker_processes -- PostgreSQL's global