Forecasts in Plain SQL: Databricks Predictive AI Functions Explained

Five new SQL functions forecast, explain, and flag strange numbers without a model. Here is how they work and what your table needs first.

Every data team gets the same three questions. What will sales be next month? Why did this number move? Is this spike normal?

Until now, most of those questions went into a queue for the data science team. Many never got asked at all.

On October 14, 2026, Databricks announced Predictive AI Functions in Beta. They are five SQL functions that forecast, find drivers, flag anomalies, and make predictions without you building a model. (Databricks announcement)

Here is what they do, how one of them works in a query, and what to watch before you trust the output.

The five functions in one table

FunctionThe question it answers
ai_forecast (upgraded)What will this number look like next?
ai_top_driversWhich segment caused this metric to change?
ai_detect_anomaliesWhich values look outside the normal range?
ai_predict_valueWhat numeric value should this row have?
ai_predict_classWhich category does this row belong to?

The important idea is not the list. It is that Databricks maintains the models centrally. You write SQL. You do not train, tune, or host anything.

How it fits into your data flow

flowchart LR
  A[Clean Silver table] --> B[Predictive AI Function in SQL]
  B --> C[Result table with scores and intervals]
  C --> D[Dashboard or Genie answer]

Notice where the function sits. It reads a table you already built. If that table has gaps, duplicates, or wrong dates, the function will forecast those mistakes with confidence.

That is why this release is really a data engineering story. The function is easy. The input table is the work.

A small example: catching a strange day

Say you have a daily revenue table per store. You want to know which days look unusual.

SELECT *
FROM ai_detect_anomalies(
  TABLE(
    SELECT
      order_date,
      store_id,
      daily_revenue
    FROM workspace.default.daily_store_revenue
  ),
  time_col  => 'order_date',
  value_col => 'daily_revenue',
  group_col => 'store_id'
)
WHERE is_anomaly = TRUE

Each store is treated as its own time series. For every day, the function uses the history before it to estimate an expected value and a range, then gives the row an anomaly score. The default threshold is 0.95. Lower it to flag more rows, raise it to flag fewer. (function reference)

Check the exact output column names in your workspace before building on them, since Beta functions can still change.

Finding why a number moved

ai_top_drivers compares two groups, a control and a test, and ranks the segments that contributed most to the change.

SELECT *
FROM ai_top_drivers(
  input   => TABLE(
    SELECT
      region,
      channel,
      revenue,
      order_month = '2026-09' AS is_september
    FROM workspace.default.monthly_sales
    WHERE order_month IN ('2026-08', '2026-09')
  ),
  metric  => 'revenue',
  is_test => 'is_september',
  dimensions => ARRAY('region', 'channel')
)

In plain words: compare September to August and tell me which region or channel explains the difference. This is the question managers ask every Monday. (function reference)

Can you try this in Free Edition?

Be honest with yourself here. These functions are in Beta. A workspace admin must turn them on from the Previews page, and they need a Pro or Serverless SQL warehouse. Some functions also add model inference cost on top of compute.

Free Edition runs on serverless, so it may work there once the preview is available to your workspace. If you do not see it, the concept still matters, and you can practice the part that matters most: building a clean daily time series table.

Three things to check before you trust a forecast

One row per time step. Timestamps must be unique within each series. Duplicate days quietly break the history the model learns from.

No silent gaps. A missing day is not the same as a zero day. Decide which one is true and fill it on purpose.

Enough history. A forecast built on three weeks of data is a guess with a chart attached. Show the interval, not just the line.

Why this matters for your career

Predictive analytics is moving from a specialist task to a SQL call. That does not make data engineers less important. It moves the value to the table underneath.

The person who builds a reliable, well-documented daily table is now the person who makes forecasting possible for the whole company.

That is a skill you can practice today, one clean table at a time.

Continue Learning