Your Databricks AI Functions need Runtime 17.3 LTS by January 2027, even if 15.4 is still supported

If a Databricks notebook or job calls ai_querydefinitionThe general-purpose AI Function. You point it at a model serving endpoint with a prompt, and it runs that model over every row you give it. or another AI Function in SQL, the runtime version under it now matters. From January 2027, those calls return an error on anything below Runtime 17.3 LTS, including 15.4 LTS and 16.4 LTS, which are still in support. Find those clusters now and test the upgrade before your change freeze.

Most teams plan runtime upgrades around end-of-support dates. That habit fails here. Runtime 15.4 LTSdefinitionLong-term support. Databricks fixes stability and security problems in an LTS runtime for three years after release. Other runtimes get six months, which is why an LTS is the one to build on. has support until 19 August 2027 and 16.4 LTS until 9 May 2028, so neither shows up on anyone's lifecycle report yet. Their AI FunctionsdefinitionSQL functions that hand your data to a model and put the answer back in the result. You'd use one to label tickets or pull fields out of documents without leaving the query. still stop in January.

When it stops, it isn't a slow degradation. Databricks says calls on runtimes below 17.3 are no longer supported and return an error. The ai_query documentation explains what an error does to the rest of the query. A failure from the model endpoint can come back as an empty result for one row when failOnError is set to false, but a row that fails for any other reason fails the entire query. This error comes from the runtime, so we'd expect it to fail the whole query. Plan for the task to stop, and for whatever reads its output table to wait.

The fix itself is easy to say: move the compute to 17.3 LTS or later. The work hides in what else changes on the way. A 15.4 LTS cluster moving to 17.3 LTS goes from Spark 3.5 to Spark 4.0, from Java 8 to Java 17 and from Scala 2.12 to 2.13. Code that ran untouched for two years tends to notice that.

Databricks lists ai_similarity as the one exception, and the AI Functions REST API isn't affected either. Everything else that needs Runtime 15.4 LTS today moves up to 17.3 LTS. That includes ai_query, the function you'd use to call your own model endpoints.

The wording in the notice is narrow on purpose. It talks about runtimes, and the compute that runs affected SQL queries. That points straight at classic clusters, where you pick the runtime yourself and it stays put until somebody changes it.

The warehouse row is our reading. Databricks' notice talks about runtime versions, and a warehouse runs a Databricks SQL version on a channel you pick, rolled out in stages. If you want certainty, run one test query on each warehouse that uses AI Functions.

Read the table from left to right and the 15.4 LTS move looks like three upgrades stacked together. Java goes from 8 to 17, Scala from 2.12 to 2.13, and Spark crosses a major version. If you run your own JARs, each of those can break the build before a single query runs.

The 16.4 LTS move is gentler, but only if you used the Scala 2.13 image. Databricks' 16.4 notes say plainly that only Scala 2.13 is supported from Runtime 17 onward, and they tell you to test on the 2.13 image before you move. Teams that stayed on the 2.12 image are in the same boat as 15.4.

There's more than one way out, and the right one depends on how much code sits on the same cluster as the AI step.

Splitting buys time; it doesn't remove the upgrade. 15.4 LTS loses support in August 2027 anyway, so treat a split as the bridge and put the full move on next year's plan.

-- example: job tasks that ran on classic clusters below 17.3 in the last 30 days
WITH clusters AS (
  SELECT workspace_id, cluster_id, cluster_name, dbr_version, owned_by
  FROM system.compute.clusters
  QUALIFY ROW_NUMBER() OVER (PARTITION BY workspace_id, cluster_id ORDER BY change_time DESC) = 1
),
task_compute AS (
  SELECT workspace_id, job_id, task_key, EXPLODE(compute_ids) AS cluster_id
  FROM system.lakeflow.job_task_run_timeline
  WHERE array_size(compute_ids) > 0
    AND period_start_time >= current_date() - INTERVAL 30 DAYS
)
SELECT DISTINCT t.workspace_id, t.job_id, t.task_key, c.cluster_name, c.dbr_version, c.owned_by
FROM task_compute t JOIN clusters c USING (workspace_id, cluster_id)
WHERE c.dbr_version RLIKE '^([0-9]|1[0-6]|17\\.[0-2])\\.'
-- then search the code of each job for ai_ functions; the system tables won't show it

That last comment is where the inventory gets harder. The query history table covers SQL warehouses, serverless notebooks and jobs, and Lakeflow pipelines. It doesn't list classic clusters running notebooks or jobs, which is exactly where this change bites. Its statement_text column is also redacted unless you're an account admin or in the databricks_pii_access group. So the system tables tell you which clusters are old, and you still have to read the code to know which ones call AI Functions.

We build and run Databricks platforms, including compute policies, serverless settings and cost reporting from system tables. For this change, we'd start with the runtime inventory and a search for AI Function calls, then test the move on clones before anything goes live. See our Databricks services, hire Databricks engineers for your own team, or start with a free assessment of which clusters and jobs January will touch.