Predict.ai vs SageMaker, BigQuery ML, and Databricks

SageMaker is a workshop

SageMaker, Vertex AI, and Databricks are excellent at a job that is not “give operations a number they can staff against on Tuesday.” They are general machine-learning platforms: notebooks, training jobs, feature stores, endpoints, experiment trackers. You can build a forecasting product on them. You will. If the vendor sold a live forecast, you would not be writing a six-month program to assemble one.

BigQuery is a warehouse that grew a forecasting function. AI.FORECAST with TimesFM (2.5 is the default) is a real zero-shot path in SQL — no CREATE MODEL, no training job. ARIMA_PLUS and ARIMA_PLUS_XREG are still there when you want a fitted statistical model and covariates. That is excellent for a path this afternoon on data that already lives in BigQuery. It is still not a prediction OS.

Predict.ai is narrower on purpose. We forecast time series — load, cash, arrivals, occupancy, shipments, claims volume — and we run the loop around that number: find drivers, race models, serve, watch, scenario. We will lose to SageMaker the day you need a custom vision model or a GPU training job that is not forecasting. We should. That is not our product.

What you still have to assemble

This is not a bake-off of whose model is smarter. Foundation models and gradient boosting show up everywhere now — Chronos and friends on SageMaker JumpStart, TimesFM inside BigQuery via AI.FORECAST, pretrained backbones in our catalog. The difference is everything around the weights:

• A walk-forward backtest that does not leak, with a naive on the same folds.
• Driver discovery that is lagged, scored, and allowed to fail in public.
• A champion you can pin, roll back, and call from the tools ops already run.
• Intervals you will actually plan on — not a center line that looks sure.
• A what-if that reuses the live model, not a second spreadsheet.
• An alert when actuals leave the band, not a static CloudWatch threshold from 2023.
• A way for an agent to create the forecast and ask why, without scraping a UI.

Count people. A “cheap” SageMaker training job is cheap until you staff the feature pipeline, the monitor, the dashboard, and the on-call when the endpoint silently serves last month’s pin. Canvas removes some of the training toil. It does not remove the operating system. A Predict.ai goal is the other end: name a target, and the loop is running in minutes — not a platform project measured in days.

SageMaker and Canvas

SageMaker is the right call when you already have an ML platform team, you live in AWS IAM, and forecasting is one of several model types you will ship. Studio, Pipelines, Feature Store, Clarify, Model Monitor, Inference Recommender — that is a serious workshop. Bring-your-own-container is a superpower we will not match for arbitrary architectures.

Canvas is the low-code face: upload a table, train a time-series model, see a forecast in the UI, optionally deploy. For an analyst who needs a path and will paste it into Excel, that can be enough. For a plant that needs p90 load every hour, with weather as a forecast of a forecast, plus a scenario if a line is down, you are back to glue. Chronos via JumpStart is a strong zero-shot. You still own serving contracts, driver search, and whether last week’s naive is beating the champion.

Where SageMaker wins

• Anything that is not a time series: vision, language, ranking, RL.
• Custom training at GPU scale, private containers, exotic nets.
• Tight coupling to the rest of an AWS estate you have already paid for.
• A large labor market. You can hire ‘SageMaker’ on a job spec.

Where we win for forecasting

We automate the forecasting job, not the general training job. A goal searches the workspace for lagged drivers, races classical models, boosters, and foundation models on purged folds, deploys the winner, and keeps it current. You can override the pick. You can bring your own model into the same tournament. With the series connected, a goal is up in minutes: drivers, a scored champion, serving. You do not staff a platform program to get a number with an interval and a what-if.

BigQuery ML

BigQuery is the right call when the series never needs to leave the warehouse and the user is a SQL analyst. Two forecasting families live there now, and they are not the same product:

• TimesFM — Google Research’s pretrained foundation model, built into BigQuery. You call AI.FORECAST (TimesFM 2.5 is the default; 2.0 is still there). No training job, no model to manage. Univariate: one target column, a timestamp, optional series ids. Confidence intervals via confidence_level. AI.EVALUATE and AI.DETECT_ANOMALIES sit next to it. Google’s own table says TimesFM does not support covariates. The open-source TimesFM 2.5 library can take XREG; that path is not what AI.FORECAST exposes.
• ARIMA_PLUS / ARIMA_PLUS_XREG — fitted statistical models. You CREATE MODEL, you get more knobs (holidays, spikes, bounds), and XREG is how you bring weather or promo if you already have those columns. Training required, one model per series.

For a one-off path, or a Looker tile that refreshes a query, this is often the easiest path to a forecast in the industry — especially TimesFM, which is minutes, not a training afternoon. Google’s docs put TimesFM results in the same neighborhood as conventional ARIMA, not as a guaranteed winner over a tournament.

It stops being a product when you need: a race of unlike model families on the same folds; driver discovery across signals that are not already columns you named; covariates on the foundation model itself (TimesFM in BQ is univariate); a pinned inference API with rollback; natural-language scenarios on a live champion; band alerts that page a person. You can approximate some of that with scheduled queries, Looker, Cloud Monitoring, and the MCP toolbox for Databases (SQL in, rows out). That is assembly again — cheaper assembly, because the data did not move, but assembly.

We are not a warehouse. If your data gravity is BigQuery, keep it there. Point Predict.ai at the series you actually decide on. Do not make TimesFM or ARIMA_PLUS pretend to be S&OP, treasury, and a contact-center roster.

Databricks and Vertex

Databricks wins when the lakehouse is already the center of gravity: Spark, Unity Catalog, MLflow, a culture that thinks in jobs and notebooks. You can train Chronos-class models, log everything, and serve. The forecasting product is still yours to write. Feature freshness, walk-forward, the planner UI, the override log — homework.

Vertex AI is SageMaker’s cousin on GCP: AutoML forecasting, custom jobs, endpoints, monitoring. Same split. Superb if you are already a Vertex shop and forecasting is one more endpoint. Incomplete as a prediction OS. If your company standardized on GCP last year, we will not win a religious war. We will win the Tuesday when finance asks for a scenario and the Vertex project is in quarter three.

What a goal automates

When you create a goal you are not clicking a nicer training job. You are handing the loop to the product. With data connected, that is minutes — not a week of glue:

• Driver discovery across the workspace — lagged, scored, multi-step paths, rejects left on the graph.
• Feature work on a schedule: lags, rolling stats, calendars — the same job that serves at 6am.
• A tournament: naive, classical, ML, foundation, and anything you brought. Same folds. You can override.
• A deployment you can pin and call. Shared or dedicated. Rollback is a pin, not a project.
• A live path that refreshes as signals land, with quantiles, not a CSV from last Thursday.
• Scenarios and sensitivity on that champion — promo, price, a line down, a heat wave.
• Alerts when actuals leave the band, instead of a flat threshold that pages every Saturday.
• An analyst that explains the move in English, and MCP tools so an agent can do the toil.

Manual mode still exists: segments, pipelines, BYOM, marketplace series. Autopilot is the default. You can still take the wheel. Notebook culture often never promotes a model, because promotion is a meeting.

Scorecard

When you should not pick us

Skip Predict.ai when:

• The work is not a time series. Classification of images, documents, or customers is a different product.
• You need a data warehouse. We connect to them. We are not one.
• A single TimesFM or ARIMA query is truly enough — one series, one analyst, no serving contract. BigQuery will be cheaper. Come back when the second team wants the same number, with drivers and a live API.
• Procurement will only buy the cloud you already committed. We can still sit on top; we will not win a “must be a first-party SKU” fight.
• You want a full IBP / S&OP workspace with financial reconciliation, like Anaplan or o9. Use those. Point them at our forecast.

Superior, for us, means the forecasting loop is a product instead of a program. It does not mean we are a bigger cloud, a cheaper warehouse, or a replacement for a data-science bench that already likes their workshop. Use the workshop for what it is for. Use a prediction OS for the number that has to show up, with an interval, after the data scientist has gone home.