AI architecture overview

Learn about the components of the Exasol architecture that are used when running AI workloads.

Exasol runs AI and machine learning workloads directly inside the database using three foundational components: user defined functions (UDFs), script language containers (SLC), and BucketFS. This article explains what each component does and how they work together.

User defined functions (UDFs)

UDFs let you write custom analysis, processing, and generation functions that execute in parallel across an Exasol cluster. They solve problems that go beyond standard SQL, such as running ML model inference or applying NLP transformations to text columns.

Exasol supports UDFs in several languages, but Python 3 is the primary language for AI workloads. You define a Python UDF by creating a script with a run(ctx) function that receives a context object for reading input data and emitting output.

GPU acceleration

In Exasol 2025.2 and later you can utilize GPUs to accelerate parallel processing for UDFs. This offers a significant performance increase for certain types of workloads, specifically those that require repetitive computations. For example, GPUs can tangibly accelerate AI and machine learning workloads, including model training and model inference. GPUs can also accelerate vector and semantic search workloads.

Script language containers (SLC)

A script language container is a packaged runtime environment that contains a programming language interpreter and all its dependencies. When you run a Python UDF, Exasol executes it inside an SLC that has Python and the required libraries installed.

Why SLCs matter for AI

AI and ML workloads depend on libraries like PyTorch, scikit-learn, NumPy, pandas, and Hugging Face Transformers. These libraries have complex dependency trees that must be consistent across all cluster nodes. SLCs solve this by bundling everything into a single deployable artifact.

Each Exasol AI extension ships with its own SLC or deploys one during installation. For example, when you run the Transformers Extension deployment command, it automatically installs an SLC containing the extension code and its dependencies (including PyTorch). The SLC is uploaded to BucketFS and registered with the database so that UDFs can reference it.

Default libraries

Exasol’s standard Python 3 SLC includes commonly used data science libraries such as NumPy, pandas, scikit-learn, and pyexasol. For AI workloads that need additional libraries (such as PyTorch), you use a specialized SLC provided by the relevant extension.

BucketFS

BucketFS is a synchronous file system available on all database nodes in an Exasol cluster. The data in BucketFS is replicated locally on every server and automatically synchronized, so each node sees the same content.

The role of BucketFS in AI workloads

BucketFS serves three purposes for AI:

Model storage

ML models (Hugging Face Transformers models, trained scikit-learn models, serialized PyTorch weights) are stored in BucketFS. The Transformers Extension downloads models from the Hugging Face Hub into BucketFS, where they remain cached for repeated inference without re-downloading. You manage models through SQL UDFs (TE_MODEL_DOWNLOADER_UDF, TE_LIST_MODELS_UDF, TE_DELETE_MODEL_UDF).

SLC hosting

Script language containers are uploaded to BucketFS as part of the deployment process. The database loads them from BucketFS when executing UDFs.

Intermediate state

For iterative workflows, BucketFS passes state and data between Lua orchestration scripts and Python UDFs. Each iteration writes its results to BucketFS, where the next iteration reads them.

Characteristics and limitations

BucketFS is a file-based system without transactional semantics. Write operations are atomic (they either complete or fail entirely), but there is no file locking, so a subsequent write to the same path overwrites the previous version. BucketFS data is not included in database backups and must be backed up separately.

Access is configured through BucketFS connection objects in SQL. For on-premises Exasol, a typical connection uses a JSON format:

CREATE OR REPLACE CONNECTION "BUCKETFS_CONNECTION"
    TO '{"url":"https://my_cluster:6583", "bucket_name":"default", "service_name":"bfsdefault"}'
    USER '{"username":"w"}'
    IDENTIFIED BY '{"password":"write_password"}';

For Exasol SaaS, the connection format uses different parameters: url (optional, defaults to https://cloud.exasol.com), account_id, database_id, and pat.

How the three components work together

A typical AI workload on Exasol follows this pattern:

1. Deploy an SLC containing the Python runtime and ML libraries to BucketFS.
2. Store models (pretrained weights, serialized model files) in BucketFS.
3. Register UDF scripts that reference the SLC and provide paths to the models in BucketFS.
4. Execute in SQL. When you call a UDF, Exasol loads the SLC and starts a Python process. The UDF reads the model from BucketFS, then processes the input data.

For example, running text classification with the Transformers Extension:

1. The deployment command uploads the SLC and registers UDF scripts.
2. You download a Hugging Face model into BucketFS using TE_MODEL_DOWNLOADER_UDF.
3. You run inference with SELECT AI_CLASSIFY_EXTENDED(...) FROM my_table, which loads the model from BucketFS inside a Python UDF and classifies each row.

Parallel processing for AI workloads

Exasol is a massively parallel processing (MPP) database. When you call a UDF in a query, Exasol distributes the work across cluster nodes automatically.

How distribution works

For SCALAR UDFs, each node processes the rows stored locally, and the run() function is called once per row. For SET UDFs, rows are grouped (typically by a GROUP BY clause) and each group can be processed by a different node. Multiple virtual machines may run on each node.

This distribution happens transparently. The UDF code does not need to be aware of the cluster topology, though it can access node information through exa.meta.node_count and exa.meta.node_id if needed.

What this means for AI

Parallel execution is particularly valuable for inference workloads. When you run a Hugging Face model against a table with millions of rows, Exasol distributes those rows across all available nodes. Each node loads the model from its local BucketFS replica and processes its share of the data independently. The database collects the results and returns them as a unified result set.

For training workflows, the current approach is to use Exasol AI Lab’s Jupyter environment or external tools.

Initialization code (such as loading a model into memory) runs once per virtual machine rather than once per row, so the cost of loading a large model is amortized across all rows processed by that VM instance.

Next steps

• Set up Exasol AI Lab to start experimenting with in-database AI