Forecasting one series is easy to prototype. Forecasting hundreds consistently is where workflow design starts to matter as much as model choice — making model comparison reproducible instead of ad hoc.
A screen recording of an R forecasting workflow in RStudio. A panel of 200 time series is declared as a tsibble with a monthly index and a series key. A single model declaration fits four baseline families — ETS, ARIMA, naive, and seasonal naive — across every series, then produces forecasts with prediction intervals and an accuracy comparison. The workflow shows that different series can favour different baselines: a stable series may favour naive, a seasonal series seasonal naive, a smoother pattern ETS, and another series ARIMA. The point is not avoiding loops for its own sake but making model comparison reproducible with a validation design that matches the real forecast horizon. All data shown is illustrative.
TL;DR: At scale, the workflow matters as much as model choice. Forecasting one series is easy to prototype; forecasting hundreds consistently is a workflow problem. In R, tsibble , fable , and feasts make a panel of series a first-class object, so a single declaration can fit four baseline families — ETS, ARIMA, naive, seasonal naive — across every series and return forecasts and intervals in a consistent format. The valuable part is not avoiding loops; it is making model comparison reproducible. Different series favour different baselines, so there is rarely one universal winner. The question is not “which model is best?” but “can my workflow evaluate sensible alternatives per series, using a realistic validation design?” Use the standard stretch_tsibble() → model() → forecast() → accuracy() workflow, match the evaluation design to the real forecast horizon, and keep the baseline set consistent rather than letting one pair of models decide the winner.
Forecasting one series is easy to prototype. Forecasting hundreds of series consistently is where workflow design starts to matter as much as model choice. At that scale, the question stops being “which forecasting model is best?” and becomes “can my workflow evaluate sensible alternatives per series, using a realistic validation design?”
Different series have different behaviour. A stable series may favour naive forecasts, a seasonal series may favour seasonal naive, a smoother pattern may suit ETS, and another series may benefit from ARIMA. There is rarely one universal winner.
This is one reason I still value the R forecasting ecosystem — especially tsibble,
fable, and feasts. A panel of series becomes a first-class object, and one
declaration can fit several baseline model families across every series, then produce forecasts and
intervals in a consistent format.
data %>%
as_tsibble(index = month, key = series_id) %>%
model(
ets = ETS(value),
arima = ARIMA(value),
naive = NAIVE(value),
snaive = SNAIVE(value ~ lag("year"))
) %>%
forecast(h = 12)The important part is not avoiding loops for its own sake. It is making model comparison reproducible. Four baseline families in one declaration means every series is evaluated the same way, with the same horizon and the same output shape.
On the validation side, the standard fable workflow is stretch_tsibble() followed by
model(), forecast(), and accuracy() — not a bespoke
cross-validation helper. The evaluation design should match the real forecast horizon, and ETS and
ARIMA alone are not enough to declare a winner per series; keep the baseline set consistent and
select on a design that reflects how the forecast will actually be used.
At scale, the workflow matters as much as model choice. Model choice can still matter greatly, but a pipeline that fits several sensible baselines per series, compares them against a realistic validation split, and reports accuracy per series is what makes the choice defensible.
That is what a mature many-series pipeline should make easy: evaluate sensible alternatives per series, reproducibly, and keep the comparison honest as the panel changes.
Design insight: At scale, the workflow matters as much as model choice.
Forecasting one series is easy to prototype; forecasting hundreds consistently is a workflow
problem. In R, tsibble, fable, and feasts make a panel of
series a first-class object, so a single declaration can fit four baseline families — ETS,
ARIMA, naive, seasonal naive — across every series and return forecasts and intervals in a
consistent format. The valuable part is not avoiding loops; it is making model comparison
reproducible. Different series favour different baselines, so there is rarely one universal
winner. The question is not “which model is best?” but “can my workflow
evaluate sensible alternatives per series, using a realistic validation design?” Use the
standard stretch_tsibble() → model() →
forecast() → accuracy() workflow, match the evaluation design to
the real forecast horizon, and keep the baseline set consistent rather than letting one pair of
models decide the winner.
At scale, the workflow matters as much as model choice. Forecasting one series is easy to prototype; forecasting hundreds consistently is a workflow problem. In R, tsibble , fable , and feasts make a panel of series a first-class object, so a single declaration can fit four baseline families — ETS, ARIMA, naive, seasonal naive — across every series and return forecasts and intervals in a consistent format. The valuable part is not avoiding loops; it is making model comparison reproducible. Different series favour different baselines, so there is rarely one universal winner. The question is not “which model is best?” but “can my workflow evaluate sensible alternatives per series, using a realistic validation design?” Use the standard stretch_tsibble() → model() → forecast() → accuracy() workflow, match the evaluation design to the real forecast horizon, and keep the baseline set consistent rather than letting one pair of models decide the winner.
This was written by Mahmoud Trigui, Senior Data Scientist. Forecasting hundreds of series is a workflow problem, not only a model problem. Use tsibble, fable and feasts to fit several baseline models per series and compare them with a validation design that matches the forecast horizon.