Connect to AI models

Learn how to connect AI models with your Exasol database.

You can connect AI models to your Exasol data through three paths. Each path represents a different trade-off between performance, capability, and data control.

In-database models

Run models directly inside Exasol as SQL-callable UDFs. Your data never leaves the database. This path gives you the best performance and lowest cost per prediction, because inference happens where the data already lives, meaning no network round-trips, and no external services to manage.

Use in-database models for:

  • Text classification, named entity recognition, translation, and other NLP tasks using pretrained Hugging Face models
  • Custom scikit-learn, PyTorch, or statistical models deployed as UDFs
  • Batch inference over large tables where latency and cost matter

This is the default choice when a smaller, task-specific model can meet your accuracy requirements. A fine-tuned BERT model running in-database will process millions of rows faster and cheaper than sending each row to a cloud API.

To learn more, see In-database models (UDFs).

Self-hosted and sovereign cloud models

Run models on infrastructure you control: a local Ollama server, Amazon Bedrock in your AWS account, or any model endpoint within your network boundary. Your data stays within your environment, but you get access to larger and more capable models than what fits inside a database UDF.

Use self-hosted and sovereign cloud models for:

  • LLM-powered workflows (summarization, complex reasoning, code generation) where in-database models lack the capability
  • Scenarios where data governance requires that data never leaves your infrastructure
  • Teams already running Ollama, vLLM, or cloud-provider AI services in their own accounts

Exasol connects to these models through UDFs that make HTTP calls to your model endpoint, or through external scripts that query Exasol and send data to the model. The MLflow model serving pattern also fits here: you host the MLflow server on your own infrastructure.

To learn more, see Foundation models (applies to both sovereign and cloud paths) and MLflow model serving.

Cloud API models

Call hosted model APIs (Anthropic, OpenAI, Google) directly. This gives you access to the most capable foundation models with no infrastructure to manage, but your data leaves the Exasol environment and you pay per token.

Use cloud API models for:

  • Tasks that require frontier model capabilities (complex reasoning, long-form generation, multimodal understanding)
  • Prototyping and interactive exploration with MCP-connected AI assistants
  • Low-volume workloads where per-token cost is acceptable

To learn more, see Foundation models (OpenAI, Anthropic, Google).

Choosing the right path

Most teams use a hybrid approach. The right question is not which path should we use? but which path fits each use case?

Question If yes...
Can a smaller, task-specific model handle this? Start with in-database. Best performance, lowest cost.
Do you need LLM capabilities but data must stay in your environment? Use self-hosted or sovereign cloud.
Do you need frontier model capabilities and data governance allows it? Use cloud APIs.
Are you processing millions of rows in batch? Prefer in-database to avoid per-row API latency and cost.
Is this interactive exploration or prototyping? Cloud APIs using MCP are the fastest path to results.

The general principle: use the smallest, closest model that meets your accuracy requirements.

In-database models are faster and cheaper. Move to external models when you need capabilities that in-database models cannot provide.

Next steps