All stacks · Lakehouse & table formats
Incremental upserts, copy-on-write vs merge-on-read, and streaming lakes.
Apache HudiCopy-on-write versus merge-on-read, incremental pulls versus snapshots, compaction as a job you schedule, and why one table gets one writer and one format.
Apache Hudi is the incremental lake table format: upserts, copy-on-write vs merge-on-read, and timeline-based incremental pulls. It grew up in streaming-into-S3 shops that needed MERGE without a warehouse.
Iceberg and Delta have more mindshare in 2026, but Hudi is still the right answer when incremental consumption and upsert-heavy CDC are the job. Compare formats; do not collect all three.
Pick Hudi when incremental ETL from CDC into object storage is the core path and your engine support is Spark-first. Pick Iceberg when multi-engine reads (Snowflake, Trino, Flink) matter more. Do not dual-write.
It is a table format with incremental pull. You still need a stream processor or Spark streaming job to land events. Hudi does not replace Kafka.
Compaction (especially MOR), cleaning old files, and clustering. Skip them and query time grows like any neglected lake table.
One email a week with our latest tutorials. No spam.
Newsletter signup is not live yet. Use the contact form if you want to be notified.