On 2 October 2026 Databricks retired Google Gemini 2.5 Pro and, in the same batch of release notes, Gemini 2.5 Flash. Both are listed as no longer available. The recommended replacements are Gemini 3.1 Pro or Gemini 3.5 Flash, and Databricks points at its deprecated and retired models page for migration guidance.
The release note doesn't describe a grace period, a shim, or automatic redirection to a successor model. It says the models are gone and names what to use instead. If you had either string hard-coded in a serving endpoint, an agent config, or a notebook, that call path stopped working on the second.
A model name isn't a stable interface #
Teams treat a hosted model identifier the way they treat a library version: pin it, get repeatable behaviour, upgrade when convenient. That mental model doesn't survive contact with a vendor-hosted catalogue. The provider decides the end date, and the platform in front of it passes that decision through. Databricks is passing on a decision Google made.
What makes this worth writing down is the pair. Pro and Flash went on the same day. The usual hedge, keep a cheap fast model and an expensive careful one from the same family so you can fail over between them, bought nothing. Both halves of the family left together, and the replacements carry a different major version number.
What to actually change #
Stop writing model names into application code. Put them in config that one person can change in one place, and record which endpoints resolve to which upstream model today. If you can't answer "which of our agents calls Gemini" in under a minute, that's the gap to close first.
The AI Gateway exists partly for this. Route through a named endpoint, swap the model behind it, and the callers never learn. We cover that pattern in Foundation Models and the AI Gateway, and the same indirection matters more for anything long-running in Agents on Databricks, where a retired model shows up as a runtime failure in a workflow nobody was watching.
There is also an evaluation cost that teams underestimate.
Moving from 2.5 to 3.1 or 3.5 isn't a drop-in swap. Prompts tuned against one checkpoint behave differently against another, tool-calling formats drift, and token costs change. Whatever evaluation set you used to pick the original model is the thing that tells you whether the replacement is acceptable. If no such set exists, you are migrating on vibes. MLflow and the Model Lifecycle is where that harness belongs.
The pattern to expect #
This will happen again, and the cadence is set by the model vendors. Gemini 2.5 was a current-generation model not long ago. Anything you are building on in October 2026 is on a similar clock.
The practical defence is boring. Keep an inventory, keep an eval set, keep the model name out of your source. Teams that already do this for database connection strings know how to do it for models. They just haven't noticed it's the same problem.
Questions people ask #
When did Databricks retire Gemini 2.5? #
Gemini 2.5 Pro and Gemini 2.5 Flash were both retired on 2 October 2026, and the release notes list them as no longer available.
What replaces Gemini 2.5 on Databricks? #
The release notes recommend Gemini 3.1 Pro or Gemini 3.5 Flash, and point to Databricks' deprecated and retired models page for migration guidance.
Update, 7 October 2026 #
Two more dated model changes landed in the October release notes. On 6 October 2026 Zhipu AI GLM 5.2 became a legacy model, with Databricks recommending GLM 5.3 or GLM 5.3 Flash instead. The same day, DeepSeek V4 Flash (0731) was given a retirement date of 5 November 2026, and DeepSeek V4.1 Flash is named as the replacement.
The two statuses aren't the same thing, and the difference is what you plan around. Legacy means the model still answers, but it's no longer what Databricks points new work at, so it is the warning shot. A scheduled retirement is the date your calls start failing. Four weeks is more notice than Gemini 2.5 got, which is worth something, though it is still short of a release cycle for anything that ships through change control.
Our position doesn't move. Pin a model name in one place, keep a cheap evaluation set you can rerun against a candidate replacement, and treat the release notes as a feed you read rather than something you find out about from a failing job. If you are on GLM 5.2 today, you have no hard deadline yet, which is exactly when the swap is cheapest to test.