Load or Query in Place? Working With Data Lakes in Exasol

Yuvaraj Muniyandi

· 29th September 2026 · 6 mins read

How the Lakehouse Query Engine, native IMPORT, and Virtual Schemas fit together

Start with the architectural decision

Analytical data rarely lives in one place. Organizations store some of it in object storage as Parquet or CSV files, some in lakehouses built on Apache Iceberg and Delta Lake, and some in other databases.

Organizations need to query and combine data across these sources without moving everything into one system. This is where data federation matters: accessing data from different systems through a common SQL interface while keeping the source data in place. Teams must also decide which results to store in Exasol for reporting, dashboards, and other analytical applications.

The first decision is whether to load that data into Exasol or query it where it already lives. Three Exasol capabilities address these requirements:

Lakehouse Query Engine: query Iceberg and Delta Lake tables in place, including Databricks-managed tables, and materialize selected results when needed.
Native IMPORT: bulk-ingest Parquet and CSV data once or regularly.
JDBC-based Virtual Schemas: query data in external databases without copying it.

Load or query in place?

Use case	Capability	Load or query in place?
Query Iceberg or Delta Lake tables	Lakehouse Query Engine	Query in place
Bulk-ingest Parquet or CSV files	Native IMPORT	Load
Query external databases	JDBC-based Virtual Schemas	Query in place

Support depends on the Exasol version, catalog, and deployment configuration.

Query Iceberg and Delta Lake in place with the Lakehouse Query Engine

A lakehouse stores analytical data in object storage, using table formats such as Apache Iceberg and Delta Lake to manage schemas, metadata, and transactions. The data itself usually sits in Parquet files, and the table format adds a layer of metadata that keeps track of which files belong to the table, what its schema looks like, and how it has changed over time. This gives you enforced data types and a tabular structure, ACID transactions, and time travel.

The catalog tracks lakehouse tables and points the query engine to their current metadata.

The Lakehouse Query Engine runs within Exasol. It uses Apache DataFusion inside Rust UDFs to query supported lakehouse tables.

The engine queries both Iceberg and Delta Lake tables in place. It connects to Iceberg-compatible catalogs (such as Lakekeeper and AWS Glue) and supports Unity Catalog for Delta Lake tables.

When a query accesses a supported lakehouse table, the engine resolves its metadata and distributes file-reading and computation across Exasol cluster nodes.

Because the Lakehouse Query Engine runs within Exasol, teams can query supported lakehouse tables without a separate query engine. This avoids the additional infrastructure, operational overhead, and query costs associated with running another engine.

For example, once the engine is installed and connected to your catalog as MY_LAKEHOUSE, you can query a lakehouse table like any other Exasol table:

SELECT id, name, score
FROM MY_LAKEHOUSE.EVENTS
WHERE score > 15.0
LIMIT 5;

You can also combine lakehouse data with existing Exasol data in a single SQL query. For example, a team can join customer activity stored in Iceberg with customer records in Exasol, without first importing the Iceberg table:

sql

SELECT c.customer_name, c.segment, e.score

FROM MY_LAKEHOUSE.EVENTS AS e

JOIN my_schema.customers AS c

  ON e.id = c.customer_id

WHERE e.score > 15.0;

The lakehouse table is read in place, while the customer table is a regular Exasol table. To see which parts of a query the engine pushes down, use EXPLAIN VIRTUAL.

To materialize selected results in Exasol, use INSERT INTO or CREATE TABLE AS SELECT:

sql
CREATE TABLE my_schema.events AS
SELECT * FROM MY_LAKEHOUSE.EVENTS;

The Lakehouse Query Engine is an open-source Exasol Labs project. See the installation guide for supported environments, catalog configurations, and setup instructions.

Example: Build Silver and Gold layers from lakehouse data

Consider a team that keeps raw data and source extracts in Iceberg or Delta Lake tables as its Bronze layer. It wants to clean and enrich that data in a Silver layer, then model it into Gold data marts for reporting and analytics.

he workflow can follow three stages:

Bronze: Raw data and source extracts remain in Iceberg or Delta Lake tables in object storage.
Silver: SQL transformations query Bronze data in place through the Lakehouse Query Engine, clean and enrich it, and materialise the results in Exasol.
Gold: SQL transformations query the required Lakehouse data in place, combine it with silver data where needed, and materialize curated analytical data marts in Exasol for reporting, dashboards, and analytics.

ELT tools such as dbt can organize these transformations into repeatable models for building and maintaining Silver and Gold datasets.

Bulk-ingest Parquet and CSV with native IMPORT

A retailer receives daily CSV exports from its sales systems and needs to analyze them alongside existing data in Exasol. Rather than repeatedly accessing external files, the team can load each delivery into Exasol for reporting and analytics.

For this workload, Exasol’s native IMPORT command bulk-loads Parquet and CSV files into persistent Exasol tables. It supports storage sources such as Amazon S3 and S3-compatible storage, Azure Blob Storage, and Google Cloud Storage.

Store credentials in an Exasol connection object rather than embedding them directly in the IMPORT statement.

sql
CREATE OR REPLACE CONNECTION my_s3_bucket
  TO 'https://my_s3_bucket.s3.eu-west-1.amazonaws.com'
  USER 'my_user'
  IDENTIFIED BY 'my_secret_key';

IMPORT INTO my_schema.my_table
  FROM PARQUET AT my_s3_bucket
  FILE 'events/2026/09/*.parquet';

Native Parquet import supports parallel loading, with additional capabilities such as glob patterns and source lineage metadata depending on the Exasol version.

Query external databases with JDBC-based Virtual Schemas

A company stores customer records in Exasol, while order information remains in an external operational database. Its analytics team needs to combine both datasets for reporting without importing the operational data into Exasol.

JDBC-based Virtual Schemas make this possible. They expose supported external database tables through Exasol SQL, allowing teams to query and join external data with persistent Exasol tables or data from other Virtual Schemas.

The external data remains at the source, while Exasol provides a common SQL interface for analyzing data across systems.

Which approach should you choose?

Query lakehouse tables in place when you build data pipelines and modern data platforms on Iceberg or Delta Lake tables, without importing them first.

Bulk-ingest with native IMPORT when you need to load large amounts of Parquet or CSV data into Exasol once or regularly.

Use JDBC-based Virtual Schemas when data in external databases should stay at the source while being accessible through Exasol SQL.

Combine them when a Lakehouse provides upstream data and Exasol stores selected transformed results. For example, a pipeline can query bronze data in place through the Lakehouse Query Engine, then materialize silver results and gold data marts in Exasol.

Takeaway

Choose the architecture first, then choose the mechanism.

The Lakehouse Query Engine Queries Iceberg and Delta Lake tables in place, running entirely inside Exasol. Native IMPORT bulk-ingests Parquet and CSV data. JDBC-based Virtual Schemas query external databases.

These approaches can work together, so you can keep source data in a Lakehouse while building curated data marts in Exasol.