Data Engineering

Delta Lake on AWS, Azure, Databricks and Snowflake

Learn how to implement Delta Lake on AWS, Azure, Databricks, and Snowflake with this guide to ACID transactions and unified data lakehouse architecture.

Published 6/15/2026 · Izan Technologies

Want this built for your team?

Senior engineers, your cloud, your IP.

Data engineers and architects are increasingly moving away from traditional data lakes toward a lakehouse architecture. At the heart of this shift is Delta Lake, an open-source storage layer that brings reliability, performance, and ACID transactions to data lakes. This technology solves the primary challenges of big data storage, such as data corruption during writes and the inability to perform updates or deletes on parquet files.

By providing a transaction log that tracks every change to the data, this storage layer ensures that readers always see a consistent view of the dataset, even while new data is being ingested. Whether you are running workloads on AWS, Azure, Databricks, or Snowflake, understanding how to leverage this format is essential for building scalable data pipelines.

What is Delta Lake and Why Does it Matter?

A standard data lake is often just a collection of files in a cloud bucket like Amazon S3 or Azure Data Lake Storage (ADLS). While cheap, these lakes lack the governance and performance of a database. This technology bridges that gap by adding a structured transaction layer on top of Apache Parquet files.

Key benefits include:

  • ACID Transactions: Ensures that data is never left in a partial state if a job fails.
  • Scalable Metadata Handling: Handles billions of files easily by treating metadata as data itself.
  • Time Travel: Allows you to query older versions of data for auditing or rollbacks.
  • Schema Enforcement: Prevents bad data from entering your lake by rejecting mismatched formats.

Implementing Delta Lake Across Cloud Platforms

The implementation of a lakehouse architecture varies slightly depending on your primary cloud provider and data warehouse strategy.

Delta Lake on Databricks

Databricks is the original creator of the technology, and it offers the most native integration. On Databricks, it is the default format. The platform uses "Liquid Clustering" and "Predictive Optimization" to automatically manage file sizes and indexing, reducing the manual tuning required by data engineers.

Delta Lake on AWS

On AWS, users typically store data in Amazon S3. You can use AWS Glue to crawl tables and make them available in the Glue Data Catalog. Services like Amazon Athena and Amazon EMR natively support reading and writing these tables, allowing for serverless SQL queries directly on your S3 buckets.

Delta Lake on Azure

Azure users benefit from the deep integration between Azure Databricks and Azure Data Lake Storage (ADLS) Gen2. Microsoft also supports this format in Azure Synapse Analytics and Microsoft Fabric, making it easier to share data between Spark engines and SQL engines without duplicating the underlying storage.

Delta Lake on Snowflake

Snowflake has expanded its support for open table formats through "Iceberg Tables" and "Delta Lake UniForm." Snowflake can read these files directly from external stages (S3/ADLS) or use the Universal Format (UniForm) to treat them as native tables. This allows organizations to keep their data in open formats while using Snowflake’s high-performance query engine.

Step-by-Step Guide to Building a Delta Lake Pipeline

Follow these steps to move from a raw data landing zone to a refined lakehouse table.

1. Initialize the Storage Layer

Create a storage bucket in your preferred cloud (e.g., S3 or ADLS). Ensure your compute environment (Spark, Glue, or Databricks) has the necessary IAM roles or Service Principal permissions to write to that location.

2. Configure the Spark Session

If you are not using Databricks, you must include the necessary JAR files in your Spark configuration to handle the transaction log.

spark = SparkSession.builder \
    .appName("IzanDeltaGuide") \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

3. Ingest and Write Data

Read your raw source (CSV, JSON, or Kafka) and write it using the "delta" format.

df.write.format("delta").mode("overwrite").save("/mnt/data/silver_table")

4. Perform Updates and Deletes

Unlike standard Parquet, you can now run DML commands.

MERGE INTO silver_table AS target
USING updates AS source
ON target.id = source.id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *

5. Optimize and Vacuum

Over time, frequent writes create small files and stale transaction logs. Run the OPTIMIZE command to compact files and VACUUM to remove files older than the retention period.

Comparison of Table Formats

While this guide focuses on one format, it is helpful to see how it compares to other open table formats like Apache Iceberg and Apache Hudi.

FeatureDelta LakeApache IcebergApache Hudi
Primary BackerDatabricksNetflix / AppleUber
ACID SupportFullFullFull
Cloud Engine SupportVery High (AWS, Azure, GCP)High (Snowflake, Cloudera)High (AWS Glue, EMR)
Schema EvolutionStrongExcellentStrong
ConcurrencyOptimistic Concurrency ControlOptimistic Concurrency ControlMulti-version Concurrency Control

Common Pitfalls and How to Avoid Them

Even with a robust framework, data teams often encounter hurdles during implementation.

  • The Small File Problem: Frequent streaming writes can create thousands of 1KB files. This kills query performance. Use the autoOptimize and setTableProperty settings to ensure the engine compacts files automatically.
  • Over-Vacuuming: Running VACUUM with a zero-day retention period breaks the Time Travel feature and can cause queries in progress to fail. Stick to the default 7-day retention unless storage costs are critical.
  • Manual File Manipulation: Never delete files directly from the S3 or ADLS folder using the cloud console. This desynchronizes the transaction log and corrupts the table. Always use the provided SQL commands.

Key Performance Indicators (KPIs) for Your Data Lake

To measure the success of your implementation, track the following metrics:

  1. Query Latency: Compare the speed of SQL queries on the new format versus raw Parquet.
  2. Storage Efficiency: Monitor the ratio of active data to "dead" files awaiting vacuuming.
  3. Job Success Rate: Track the reduction in failed pipelines due to schema mismatches or write conflicts.
  4. Data Freshness: Measure the time from data arrival in S3/ADLS to its availability in the refined tables.

FAQ: Delta Lake Guide

Is Delta Lake better than Parquet?

It is not a replacement for Parquet but a layer on top of it. While Parquet is a file format, this is a table format that adds a transaction log. You get the compression benefits of Parquet with the management capabilities of a database.

Does Snowflake support Delta Lake?

Yes, Snowflake supports it through External Tables and the newer UniForm feature. This allows Snowflake to read the transaction logs of these tables directly from your cloud storage without moving the data into Snowflake's proprietary storage.

How do I handle schema evolution in a data lake?

You can enable schema evolution by setting .option("mergeSchema", "true") during a write operation. This allows the table to automatically add new columns when they appear in the source data without failing the pipeline.

Can I use Delta Lake without Databricks?

Yes, it is a fully open-source project. You can run it on local Spark clusters, AWS EMR, Google Cloud Dataproc, or Azure Synapse. While Databricks provides proprietary performance optimizations, the core functionality remains available in the open-source version.

How Izan Technologies Can Help

Building a modern data architecture requires deep expertise in cloud-native tools and open-source standards. At Izan Technologies, we specialize in designing and implementing high-performance data lakes on AWS, Azure, and Databricks.

Our engagement model is unique: our clients own 100% of the Intellectual Property (IP) for every line of code, pipeline, and architecture we build. We believe your data infrastructure should be your asset, not a locked-in vendor dependency. Whether you need to migrate from a legacy Hadoop cluster or optimize your current Snowflake environment, our senior consultants ensure your data is reliable, governed, and ready for AI.

Ready to see it in action? Visit izan.tech/demos to request a free DataStudio demo and see how we build production-ready lakehouse architectures.

Want this built for your team?

Senior engineers, your cloud, your IP.