topic Official databricks-openai package fails to import after resolving databricks-vectorsearch in Generative AI

Official databricks-openai package fails to import after resolving databricks-vectorsearch

mbecker — Mon, 08 Jun 2026 13:35:48 GMT

I filed a detailed GitHub issue here:

https://github.com/databricks/databricks-ai-bridge/issues/433

Summary:

A clean install of `databricks-openai==0.15.0` currently resolves `databricks-vectorsearch==0.74`, after which the documented import fails:

```python
from databricks_openai import DatabricksOpenAI
```

with:

```text
ImportError: cannot import name 'VectorSearchIndex' from 'databricks.vector_search.client'
```

`pip check` reports no broken requirements.

This appears to be caused by `databricks-openai` eagerly importing vector-search retriever code, combined with the recent `databricks-vectorsearch` / `databricks-ai-search` package transition.

The immediate workaround appears to be:

```bash
python -m pip install "databricks-vectorsearch<0.74"
```

but that is not a good production story for an official Databricks package.

I’m trying to understand:

1. Is `databricks-openai` intended to be production-supported?
2. Is `databricks/databricks-ai-bridge` the correct place to report bugs for `databricks-openai`, `databricks-vectorsearch`, and `databricks-ai-search`?
3. Where is the source repository for `databricks-vectorsearch` / `databricks-ai-search`?
4. Should production users avoid `databricks-openai` and use the upstream `openai` client directly with a Databricks serving endpoint `base_url` instead?
5. Will Databricks publish a patch release or add dependency constraints to prevent this broken default install?

This is concerning because the default installation path for an official Databricks package currently results in a broken import in a clean environment, while the related PyPI pages do not clearly identify the source repository or issue tracker.

Re: Official databricks-openai package fails to import after resolving databricks-vectorsearch

iyashk-DB — Wed, 15 Jul 2026 17:59:37 GMT

Good news, this is already fixed. A Databricks maintainer confirmed the bug on your GitHub issue and shipped databricks-openai==0.16.0 together with databricks-ai-bridge==0.20.0 on June 10 to resolve it. So the actual fix, instead of pinning databricks-vectorsearch<0.74, is just to upgrade:

python -m pip install -U "databricks-openai>=0.16.0"

That pulls in the compatible databricks-ai-bridge version and the import works normally again.

On your other questions:

databricks/databricks-ai-bridge is the right place to file issues, it's the source repo that publishes databricks-openai, and it clearly is actively monitored, your issue went from filed to root-caused to a released fix in four days.

For databricks-vectorsearch and databricks-ai-search, they come from the same repo. The short version of why this broke: Vector Search was renamed to AI Search, databricks-ai-search is the new canonical package, and databricks-vectorsearch is now kept around as a thin compatibility shim that re-exports from databricks-ai-search with a deprecation warning. That rename and shuffle is almost certainly what shifted the symbol databricks_openai's retriever tool was importing.

On using the plain openai client instead, that's a legitimate and fully documented path if all you need is chat completions against a serving endpoint. Point the OpenAI client at <your-workspace-url>/serving-endpoints as the base URL and use a Databricks PAT as the API key, no databricks-openai package required. You'd only need databricks-openai specifically for the extra convenience wrappers, like the Unity Catalog function toolkit or the vector search retriever tool integration, that the plain client doesn't give you.