Delta Lake on AWS S3 vs Azure OneLake

Delta Lake is an open table format: the same _delta_log transaction log and Parquet files work on any object store, and tables can be read by Spark, Databricks, DuckDB, Polars, Trino, and a growing list of engines. But while the format is portable, the object store underneath it is not a neutral choice. The store determines the correctness guarantees your commits rely on, how well third-party tools interoperate with your tables, and how much operational friction your platform team absorbs.

This page compares the two most common foundations for Delta Lake in each cloud: Amazon S3 and Microsoft OneLake. If you are weighing a broader platform move, see our Databricks on AWS vs Azure comparison and our Azure to AWS migration services.

Where OneLake shines

OneLake deserves real credit for what it does well. It gives a Fabric tenant a single logical lake: every workload (lakehouses, warehouses, KQL databases, Power BI) reads the same physical copy of the data, and shortcuts make external data appear local without copies. For organizations standardized on Power BI, Direct Lake mode reading Delta tables straight out of OneLake, with no import and no refresh pipeline, is a genuinely differentiating capability. Capacity-based pricing also bundles storage transactions into a predictable bill, which many Microsoft-centric organizations prefer.

If your Delta tables are produced and consumed almost entirely inside Microsoft Fabric, OneLake is the natural home for them.

Where the friction shows up

The picture changes when Delta tables on OneLake need to work reliably with engines outside Fabric, such as Databricks, EMR, or open-source readers and writers, or when you need strong guarantees under concurrent writers.

OneLake is an emulation of ADLS Gen2, not ADLS Gen2

OneLake exposes an ADLS Gen2-compatible endpoint, but it implements that surface with subtle behavioral differences, and those differences have repeatedly broken open-source Delta clients. A representative sample of issues filed against delta-io/delta-rs , the library behind the Python deltalake package, Polars' write_delta, and many Rust-based tools:

• #1418: Add Support for Microsoft OneLake: the original support request; writes to OneLake left temporary commit files in the transaction log instead of completing cleanly.
• #4414: OneLake Integration issues: an epic tracking the fact that OneLake "doesn't properly support the startFrom query pattern like it is supposed to," requiring a workaround in the upstream object_store crate before listing the transaction log worked reliably.
• #4401: vacuum fails with "Error performing bulk delete request": OneLake's batch-delete endpoint rejected the standard ADLS Gen2 bulk delete call with a 400 Bad Request, breaking VACUUM.
• #4397: 1.5.1 regression: OneLake broken: a client release broke reads and writes against OneLake entirely ("No files in log segment"); the same root cause broke DuckDB's Delta extension through delta-kernel-rs.
• #3243: OneLake incompatible with rustls, #1803: Delta write in Fabric notebook failing with SSL error, and #2449: CaUsedAsEndEntity error in Microsoft Fabric: a series of TLS/certificate quirks specific to Fabric's OneLake endpoints that did not occur against other object stores.

None of these are fatal, and Microsoft and the Delta community have fixed or worked around each one. But the pattern matters: because OneLake behaves almost, but not exactly, like the ADLS Gen2 API it emulates, every client release carries a risk of OneLake-specific regressions that S3 users simply never see. Your platform team becomes part of the compatibility test suite.

Metadata freshness and sync overhead

Fabric's own community forums document the operational texture of Delta on OneLake: multi-minute delays before newly committed data becomes visible to the lakehouse SQL endpoint, and troubleshooting guidance for tables that are not checkpointed or infrequently checkpointed, which degrades read performance until maintenance runs. In one reported case, the background metadata sync ("framing") over a frequently updated Delta table consumed roughly 300,000 capacity units over two weeks with almost no end-user activity; metadata churn on OneLake is metered against the same capacity you pay for queries.

Why S3 is the stronger foundation

Delta Lake's reference target

S3 is where Delta Lake was born and where the ecosystem tests first. Every engine, from Apache Spark and Databricks to delta-rs, DuckDB, Polars, Daft, Trino, and Athena, treats S3 semantics as the baseline. When you read about a Delta Lake feature, the defaults, the examples, and the CI pipelines all assume S3 behavior. That asymmetry compounds quietly into fewer surprises, faster upgrades, and a much larger pool of production-hardened experience to draw on.

Native atomic commits, no shim required

Delta Lake's transaction protocol depends on put-if-absent semantics for its commit files. Amazon S3 has offered strong read-after-write consistency for all applications since 2020, and added native conditional writes (If-None-Match / If-Match), which modern Delta clients use directly for atomic commit coordination, with no DynamoDB lock store, no compatibility emulation layer, no edge cases between what the store advertises and what it implements.

Throughput that scales horizontally

S3 supports 3,500 PUT and 5,500 GET requests per second per prefix, and scales across as many prefixes as you create, and a Delta table's partitioned layout maps naturally onto this. Bulk maintenance maps onto purpose-built services: S3 Batch Operations for large deletes, S3 Inventory for audits, and lifecycle policies to tier cold table history into cheaper storage classes automatically.

Portability as an exit strategy

Tables on S3 are readable by everything, from anywhere, by any vendor's engine. That is not just a technical property; it is commercial leverage. Your data layer stays decoupled from any single SaaS tenant or capacity SKU, which keeps your future options open whether you stay on AWS, adopt a second cloud, or change query engines.

How to choose

Choose OneLake if your analytics estate is Fabric end-to-end and Power BI Direct Lake is the star of the show.

Choose S3 if correctness under concurrent writers, third-party engine compatibility, operational predictability, or long-term portability rank higher than keeping everything inside one Fabric tenant.