BigQuery ML: what it is, model types and a working example
BigQuery ML lets you train and use machine learning models with SQL, where the data already is. This guide lists the model types Google documents, walks through create, evaluate and predict, shows a forecast that needs no model at all, and says plainly when BigQuery ML is the wrong tool.
BigQuery ML is the part of BigQuery that creates and runs machine learning models with SQL. You write a CREATE MODEL statement over a query, BigQuery trains the model and stores it in a dataset next to your tables, and you get predictions back with another query. The data never leaves the warehouse.
It exists for one reason, which Google’s introduction to ML in BigQuery states directly: ML normally needs Python and framework knowledge, which excludes “data analysts who understand the data”. BigQuery ML lets the person who knows the tables build the model.
Note: Originally published in February 2025. Fully updated in October 2026 against Google’s current documentation, with a forecast query that was run for this article.
The fastest way to see it work
The fastest way to see it work
You do not need to train anything to try it. AI.FORECAST uses a built-in time series model (TimesFM, in preview as of October 2026) and takes a query as input. This forecasts the next seven days of a daily metric:
SELECT
forecast_timestamp,
ROUND(forecast_value) AS forecast,
ROUND(prediction_interval_lower_bound) AS low,
ROUND(prediction_interval_upper_bound) AS high
FROM AI.FORECAST(
(SELECT order_date, SUM(amount) AS revenue
FROM mydataset.orders
WHERE order_date >= '2026-04-01'
GROUP BY order_date),
data_col => 'revenue',
timestamp_col => 'order_date',
horizon => 7)
ORDER BY forecast_timestamp;We ran this shape of query on 6 October 2026 against six months of a real daily series. It returned seven rows, each with a forecast and a lower and upper bound, and it reproduced the weekly pattern in the data without being told about it: the two weekend days came out at roughly half of the weekdays. It scanned about 104 MiB.
Read the bounds, not just the middle number. On that series the upper bound was more than double the lower one for most days. A forecast is a range, and a report that shows only the midpoint is promising more than the model said.
What BigQuery ML can build
The model types, as Google’s documentation groups them (checked October 2026).
Trained inside BigQuery:
| Model | Use it for |
|---|---|
| Linear regression | predicting a number: revenue, order value |
| Logistic regression | predicting a class: will churn or not; up to 50 classes |
| K-means clustering | grouping rows into segments, with no labels needed |
| Matrix factorization | product recommendations |
| PCA | reducing many columns to a few |
Time series (ARIMA_PLUS, ARIMA_PLUS_XREG) |
forecasting and anomaly detection |
| Contribution analysis | what drove a change in a metric |
Trained outside, used from SQL: deep neural networks, Wide & Deep, autoencoders, boosted trees (XGBoost), random forest and AutoML. BigQuery hands the training to Google’s managed ML platform and keeps the SQL interface.
Remote models point at a model deployed elsewhere, including Gemini models, so you can call it from a query. Imported models bring in something trained outside BigQuery, in ONNX, TensorFlow, TensorFlow Lite or XGBoost format.
For a first model, the choice is short: a number means linear regression or boosted trees, a yes or no means logistic regression, a series over time means ARIMA_PLUS or AI.FORECAST, and “find groups” means k-means.
OWOX Data Marts
See your first report built in real time. 15 minutes.
- Connect your data warehouse
- Pick your metrics
- Get a live Google Sheets report
In the time it takes to write a ticket. Then imagine never writing that ticket again.
Book a DemoWe'll use your actual use case
The workflow: create, evaluate, predict
The workflow: create, evaluate, predict
Three statements. They follow Google’s reference syntax and were not executed for this article, because CREATE MODEL writes to a dataset.
1. Train. A model that predicts whether a customer will order again:
CREATE OR REPLACE MODEL mydataset.repeat_buyer
OPTIONS (
model_type = 'LOGISTIC_REG',
input_label_cols = ['will_reorder']
) AS
SELECT
orders_last_90d,
avg_order_value,
days_since_last_order,
will_reorder
FROM mydataset.customer_features
WHERE snapshot_date < '2026-07-01';Every column in the SELECT except the label becomes a feature. BigQuery splits the rows into training and evaluation sets on its own.
2. Evaluate. Check the model on data it has not seen:
SELECT *
FROM ML.EVALUATE(
MODEL mydataset.repeat_buyer,
(SELECT orders_last_90d, avg_order_value,
days_since_last_order, will_reorder
FROM mydataset.customer_features
WHERE snapshot_date >= '2026-07-01'));For a classifier this returns precision, recall, accuracy and ROC AUC. Evaluating on a later period, as here, is stricter than a random split and closer to how the model will be used.
3. Predict.
SELECT
customer_id,
predicted_will_reorder,
predicted_will_reorder_probs
FROM ML.PREDICT(
MODEL mydataset.repeat_buyer,
(SELECT * FROM mydataset.customer_features
WHERE snapshot_date = CURRENT_DATE()));The output is a table, so it can be saved, joined and reported on like any other query result.
Two more functions are worth knowing from the start: ML.EXPLAIN_PREDICT shows which features pushed each prediction, and ML.FEATURE_INFO describes the inputs the model saw.
What it costs
BigQuery ML is billed as BigQuery compute. Under capacity pricing, Google’s pricing page says slot capacity “applies to query costs, including BigQuery ML”. On demand, training and prediction have their own rates on the same pricing page, and they differ by model type, so look yours up before training on a large table.
Two facts from the documentation help you estimate. You can dry-run CREATE MODEL for internally trained models to see how much data it will process. You cannot for externally trained ones. And creating a remote model processes no bytes at all.
The general cost rules still apply: the training query scans the columns it selects, so select only the features. See BigQuery pricing.
When BigQuery ML is the right tool, and when it is not
When BigQuery ML is the right tool, and when it is not
It fits when the data is already in BigQuery, the problem is a standard one on tabular data (a number, a class, a segment, a forecast), and the people who will maintain it write SQL.
It does not fit when you need custom model architectures, fine control over training, or real-time predictions with strict latency. And it does not remove the hard part. The documentation says you can build a model “even without much ML knowledge” and, in the next sentence, that knowing feature engineering and training “helps you optimize both your data and your model”. Both halves are true.
The model is the easy part
A CREATE MODEL statement is a dozen lines. What decides whether its predictions mean anything is the query underneath it:
- Is the label defined the way the business defines it? “Will reorder” within 30 days or 90?
- Does any feature leak the answer? A column that is only filled in after the outcome is known will produce a model that looks excellent and predicts nothing.
- Is the training query the same as the prediction query? If a feature is computed one way in July and another way in October, the model is scoring data it was not trained on.
The third one is where projects quietly fail, and it is not an ML problem. It is the ordinary problem of the same logic written twice.
That is where a governed definition helps. In OWOX Data Marts a Data Mart is your SQL, saved with a description and an owner and run in your warehouse; the feature table a model trains on and the one it predicts on can be the same Data Mart. OWOX does not train models, pick features or run BigQuery ML for you. It keeps the query both steps depend on from drifting apart.
Turn your data into decisions.
Governed data marts give you the clean foundation ML needs to actually work.
- No AI hallucinations
- Analyst-governed definitions
- Every number traces to SQL
Frequently Asked Questions
Can I forecast in BigQuery without training a model?
Yes. AI.FORECAST takes a query with a timestamp column and a value column and returns a forecast with lower and upper bounds, using the built-in TimesFM model, in preview as of October 2026.
How is BigQuery ML priced?
As BigQuery compute. Under capacity pricing, slot capacity covers BigQuery ML. On demand, training and prediction have their own rates per model type on Google's BigQuery pricing page. Creating a remote model processes no bytes.
What is the difference between internally and externally trained models in BigQuery ML?
Internally trained models, such as linear and logistic regression, k-means and ARIMA_PLUS, are built in to BigQuery ML. Externally trained ones, such as DNN, boosted trees and AutoML, are trained on Google's managed ML platform and used from SQL. You can dry-run CREATE MODEL only for the internal ones.
When should I not use BigQuery ML?
When you need custom model architectures, fine control over training, or real-time predictions with strict latency. It suits standard problems on tabular data that is already in BigQuery and is maintained by people who write SQL.
What types of models can I build with BigQuery ML?
Trained inside BigQuery: linear regression, logistic regression, k-means clustering, matrix factorization, PCA, time series (ARIMA_PLUS) and contribution analysis. Trained externally and used from SQL: deep neural networks, Wide & Deep, autoencoders, boosted trees, random forest and AutoML. You can also use remote and imported models.
What is BigQuery ML?
The part of BigQuery that creates and runs machine learning models with SQL. A CREATE MODEL statement trains a model on the result of a query and stores it in a dataset, and functions such as ML.PREDICT return predictions as a table.
