BigQuery now offers a native multivariate forecasting foundation model called TimesFM 3.0, extending the existing zero‑shot AI.FORECAST capability from single‑series predictions to joint forecasts that incorporate multiple targets and past‑only covariates. Engineers care because the change lets them keep forecasting logic inside SQL while handling richer business signals without building or maintaining custom models.
What’s New in TimesFM 3.0
TimesFM 3.0 is a 330‑million‑parameter model that currently leads three public time‑series leaderboards (GIFT‑Eval, FEV‑Bench, TIME) for zero‑shot accuracy on both covariate and multivariate tasks. Compared with the earlier TimesFM 2.0/2.5 releases, the new model adds:
- Forecasting scope: support for both univariate and multivariate scenarios.
- Target handling: ability to predict a single column or a set of columns in the same query.
- Covariate support: inclusion of past‑only driver columns such as weather, promotions, or holidays.
- Drop‑in upgrade path: existing AI.FORECAST and AI.DETECT_ANOMALIES calls work by changing the model argument to
model => 'TimesFM 3.0'.
Impact on Architecture and Implementation
From an architecture perspective, the model remains a fully managed service; there is no need to provision GPUs, store checkpoints, or orchestrate training pipelines. The primary change is in the query shape. Engineers must now supply a target_columns list and optionally a covariate_columns list when invoking AI.FORECAST. This shifts some data‑preparation work upstream: the source table must contain all relevant drivers with timestamps aligned to the target series, and the schema should expose each driver as a separate column.
Because the model runs inside BigQuery, the compute cost is still billed as part of the query execution. Multivariate forecasts typically increase the amount of data read and the size of the result set, so practitioners should monitor query bytes processed and consider partitioning or clustering strategies to keep costs predictable.
Operational and Security Considerations
Operationally, TimesFM 3.0 continues the zero‑shot paradigm: no training jobs, no model versioning, and no separate monitoring of model drift. The primary operational signal is the query success/failure and the statistical quality of the forecast output, which can be validated with downstream anomaly detection or back‑testing pipelines.
Security posture does not change dramatically. Access to AI.FORECAST and AI.DETECT_ANOMALIES remains governed by the same IAM permissions that protect other BigQuery ML functions. However, because multivariate forecasts ingest additional columns that may contain sensitive driver data, teams should review column‑level access controls and data‑loss‑prevention policies to ensure that only authorized roles can include those columns in a forecast request.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
Practitioners should evaluate existing forecasting pipelines for opportunities to replace custom models with a simple AI.FORECAST call that specifies model => 'TimesFM 3.0'. When doing so, they need to:
- Identify relevant covariate columns and confirm they are stored as past‑only values.
- Adjust the query to list all target columns that require joint prediction.
- Update cost monitoring to account for larger result sets.
- Validate that IAM and column‑level policies cover the newly exposed driver data.
By treating TimesFM 3.0 as a managed extension of existing SQL‑based forecasting, teams can accelerate the adoption of multivariate analytics while keeping the operational surface area minimal.