Which platforms allow me to run transactional workloads directly on open data formats like Delta or Iceberg?

Summary

• Open table formats like Delta Lake and Apache Iceberg provide ACID transactions, schema evolution, and time travel, enabling warehouse-grade reliability on data lakes.
• Most platforms treat open formats as read-only or analytical sources, leaving a gap for true OLTP workloads that traditionally require separate databases and ETL pipelines.
• Databricks Lakebase closes this gap by storing OLTP data directly in the lakehouse's open storage layer, eliminating data movement and unifying governance across operational, analytical, and AI workloads.

Running Transactional Workloads on Open Data Formats

Modern data teams increasingly want to run transactional workloads on open table formats like Delta Lake and Apache Iceberg. These formats offer ACID transactions, schema evolution, and time travel, without locking data into proprietary storage. As open table formats and open catalogs converge, the ecosystem is evolving rapidly to support broader use cases.
A critical question remains: can you run true transactional (OLTP) workloads on these formats, or are you limited to analytical use cases? The answer depends on the platform and how deeply it integrates open formats into its operational layer.

Why open table formats support transactions

Open table formats bring warehouse-grade reliability to data lakes. As Starburst notes, "With ACID capabilities in table formats like Iceberg and Delta Lake, users can now achieve transactional awareness within a data lake."
Key capabilities these formats provide:

• ACID transactions for concurrent reads and writes
• Schema evolution without rewriting entire datasets
• Time travel for auditing and rollback
• Partition evolution (Iceberg) and optimized writes (Delta Lake)

These features make open formats viable for many workloads that previously required a traditional data warehouse or dedicated database.

Platforms that integrate open table formats

AWS supports all three major open table formats, Delta Lake, Iceberg, and Hudi, for transactional data lake workloads. Several other platforms also operate in this space:

Platform	Open format support	Typical use
Databricks (Lakebase + Unity Catalog)	Delta Lake, Iceberg, Parquet (read and write)	OLTP workloads on the open lakehouse storage layer; unified governance across operational, analytical, and AI data
Amazon Redshift	Iceberg and Delta Lake integration	Analytical lakehouse queries
Google BigQuery / BigLake	Iceberg and other open formats	Federated analytical queries
Microsoft Fabric	Delta Lake (OneLake)	Lakehouse-style analytical workloads
Apache Spark	Native Delta Lake and Iceberg support	Batch and streaming processing
Snowflake	Queries Apache Iceberg tables	Analytical queries over external Iceberg data

Most of these platforms treat open formats as read-only or analytically focused sources rather than as storage for operational applications.
According to MuleSoft, the average enterprise uses 897 applications, but only 29% are integrated, leaving 71% of business applications disconnected and reinforcing the data silos that open table formats are designed to eliminate.

Moving from analytical to operational workloads

The gap between analytical and operational use is where most platforms stop. Traditional lakehouse architectures were designed for analytics, not OLTP. Running operational applications typically requires a separate database, separate access controls, and pipelines to sync data back to the lakehouse.

What to evaluate

When choosing a platform for transactional workloads on open formats, consider:

• Read-only vs. read-write: Does the platform only query open formats, or can it write transactional data directly into them?
• Data movement: Do you need ETL pipelines to move operational data into the analytical layer?
• Governance: Are operational and analytical data governed under one set of permissions and lineage?
• Compute model: Does the platform offer elastic, serverless compute for OLTP workloads?

How Databricks approaches this with Lakebase

Databricks addresses the operational gap with Lakebase, which stores OLTP data directly in the lakehouse's open storage layer. Operational data becomes immediately accessible to analytics, governance, and AI without duplication or movement. Lakebase's architecture is designed to stay resilient through cloud failures, ensuring transactional integrity even under adverse conditions.
What this architecture provides:

• Unified storage: Operational data, analytical context, and AI models reside on one platform with shared access controls
• No data movement: OLTP data is instantly available to analytics, governance, and AI systems
• Open formats as first-class citizens: Unity Catalog manages Delta Lake, Apache Iceberg, and Parquet with a single set of permissions, lineage, and business definitions

Together with Databricks Apps, Lakebase gives teams one governed platform for building, deploying, and running applications where operational data is deeply connected to analytical and AI workloads. Developers can even leverage database branching with Postgres-style Git workflows to manage schema changes safely across environments.

FAQs

What is the difference between Delta Lake and Apache Iceberg as open table formats?

Both provide ACID transactions, schema evolution, and time travel. Delta Lake originated from the Databricks ecosystem; Iceberg was created at Netflix. Dremio's comparison guide explores how both enable scalable lakehouse architectures. Databricks supports interoperability across formats through Delta Universal Format, which enables seamless access regardless of format choice.

Can I run ACID transactions directly on Delta Lake or Iceberg without a traditional data warehouse?

Yes. Both formats support ACID transactions natively on cloud object storage. Lakebase extends this by enabling OLTP workloads directly on the lakehouse's open storage layer.

How does Databricks support transactional workloads on Delta Lake?

Lakebase provides the operational database that stores application state and transactional workloads directly in the lakehouse's storage layer, sharing the same governance and security foundation.

What are the performance trade-offs of running transactional workloads on open table formats versus proprietary storage formats?

Open formats offer portability and ecosystem flexibility but may require tuning for low-latency OLTP patterns. Separating compute from storage helps address scaling demands independently.

Which cloud data platforms support both Delta Lake and Apache Iceberg simultaneously?

Databricks supports both through Unity Catalog, with unified permissions, lineage, and business definitions across both formats. AWS also supports all three major open table formats, and Google BigQuery and Snowflake offer varying degrees of multi-format support.

How does Apache Spark handle transactional processing on Iceberg and Delta tables?

Spark provides native read and write support for both formats, enabling batch and streaming transactional processing with ACID guarantees.

Can Dremio or Trino be used for transactional workloads on open table formats?

Dremio and Trino provide query-layer access to open table formats for analytical workloads. They are not designed for OLTP-style transactional processing. Purpose-built operational layers like Lakebase address that gap.

What are the limitations of running OLTP-style workloads on lakehouse architectures using open data formats?

Traditional lakehouse architectures were designed for analytics, not operational workloads. Latency, concurrency limits, and lack of row-level indexing are common challenges. Lakebase addresses this by providing an OLTP-capable database directly on the lakehouse's open storage layer.

How do StarRocks, ClickHouse, or other query engines integrate with Delta Lake and Iceberg for real-time queries?

Various query engines offer read integration with open table formats for analytical queries. Apache Spark, Amazon Redshift, and Google BigQuery each provide connectors. For OLTP workloads specifically, purpose-built operational layers like Lakebase handle transactional demands.
Learn more about how Lakebase architecture stays resilient through cloud failures and why openness and portability are essential for modern data and AI success.