voonhous commented on code in PR #19320:
URL: https://github.com/apache/hudi/pull/19320#discussion_r3613710763
##########
website/blog/2026-07-17-async-compaction-background-maintenance.mdx:
##########
@@ -0,0 +1,240 @@
+---
+title: "Async Compaction: Background Maintenance as an Architectural Primitive"
+excerpt: "Async compaction in Hudi is not a performance tweak layered onto
ingestion — it is the natural consequence of a storage engine that separates
correctness from optimization, a principle mature databases have followed for
decades."
+description: "Async compaction in Hudi is not a performance tweak layered onto
ingestion — it is the natural consequence of a storage engine that separates
correctness from optimization, a principle mature databases have followed for
decades."
+authors: [sivabalan]
+category: deep-dive
+image:
/assets/images/blog/2026-07-17-async-compaction-background-maintenance/mor-separates-correctness-from-optimization.png
+tags:
+- mor
+- merge on read
+- compaction
+- architecture
+- data lakehouse
+- metadata
+- clustering
+---
+
+---
+
+_This is the fourth post in a series on Merge-On-Read as an architectural
shift in Apache Hudi. The [first
post](/blog/2026/05/14/mor-isnt-a-storage-optimization-its-an-architectural-shift)
made the broad case; the
[second](/blog/2026/06/05/why-metadata-has-to-be-mutation-friendly) showed how
the metadata table inherits the same append-first model; the
[third](/blog/2026/06/25/building-indexes-on-a-moving-target) traced how async
indexing extends the pattern to live index construction. This one follows the
pattern one step further — into how storage optimization itself becomes an
independent concern._
+
+---
+
+<div style={{ fontSize: '1.15rem', lineHeight: '1.75' }}>
+
+Every storage system eventually accumulates technical debt. As data is
continuously written, small files begin to appear, updates scatter across
existing layouts, indexes drift away from the latest state, and storage
gradually becomes less efficient for analytical queries. Left unattended, write
performance deteriorates, read latency increases, and operational costs
steadily rise. Storage optimization is therefore not an optional feature — it
is an unavoidable consequence of maintaining a long-lived data system.
+
+The question is **not whether maintenance should happen, but when it should
happen.**
+
+Traditional database systems answered this question decades ago. They
established a simple but profound principle: user transactions are responsible
for correctness, while background maintenance is responsible for efficiency.
Operations such as
[VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html) in
PostgreSQL,
[compaction](https://en.wikipedia.org/wiki/Log-structured_merge-tree) in
LSM-based databases, online index builds, and checkpointing continuously
improve the storage engine without becoming part of the critical transaction
path. Applications continue writing data while the storage engine quietly
reorganizes itself in the background.
+
+The first generation of lakehouse table formats emerged under a different set
of assumptions. They were designed during a period when most analytical
datasets were largely append-only, refreshed through scheduled batch pipelines,
and stored as immutable Parquet files on object storage. Snapshot isolation and
file replacement naturally became the dominant architectural primitives,
providing a simple and robust foundation for managing analytical data at scale.
+
+Today's workloads are fundamentally different. Change Data Capture (CDC),
streaming ingestion, operational analytics, feature stores, and AI pipelines
have transformed lakehouses into continuously mutating systems. Storage
optimization is no longer an occasional maintenance task performed after
nightly ETL jobs — it must coexist with thousands of ongoing updates without
delaying ingestion or compromising data freshness.
+
+This raises an architectural question that modern databases answered decades
ago, but that is becoming increasingly relevant for lakehouses:
+
+**Should storage optimization compete with writes, or should it evolve
independently?**
+
+Apache Hudi's Merge-On-Read architecture approached this question differently
from the beginning. Introduced in 2017, with asynchronous compaction following
in 2019, it treated background maintenance not as an optimization layered onto
the write path, but as a foundational architectural primitive. At the time,
these capabilities were often viewed as implementation details that improved
write performance. Looking back, they represented something much deeper: a
different philosophy for organizing work inside a mutable storage engine.
+
+---
+
+## The Evolution of Background Maintenance
+
+Every long-running storage system eventually converges on the same
realization: maintaining correctness is only half the problem. The other half
is maintaining efficiency.
+
+Every storage engine continuously makes local decisions. A newly inserted row
is written wherever space is available. An updated record is appended to a
write-optimized structure. An index is modified just enough to preserve
correctness. Each individual operation is intentionally optimized for low
latency.
+
+Over time, however, thousands or millions of these local decisions accumulate.
Data becomes fragmented. Small files proliferate. Obsolete versions remain on
disk. Physical layouts drift away from what analytical queries would ideally
prefer.
+
+Left unattended, the storage engine gradually becomes less efficient — not
because anything is incorrect, but because correctness alone does not guarantee
an optimal physical layout.
+
+This distinction gave rise to one of the most important architectural ideas in
modern databases: **background maintenance**.
+
+<div style={{ textAlign: 'center' }}>
+ <img
src="/assets/images/blog/2026-07-17-async-compaction-background-maintenance/background-maintenance-across-storage-engines.png"
alt="Background maintenance across storage engines" width="800"/>
+</div>
+
+This philosophy appears across nearly every mature storage engine, although
the implementation differs.
+
+PostgreSQL periodically runs **VACUUM** to reclaim obsolete row versions
created by MVCC. LSM-tree based systems such as
[RocksDB](https://github.com/facebook/rocksdb/wiki/Universal-Compaction),
[LevelDB](https://github.com/facebook/rocksdb/wiki/Leveled-Compaction),
Cassandra, and ScyllaDB continuously compact SSTables to reduce read
amplification and reclaim space. SQL Server and Oracle rebuild indexes online,
while checkpointing mechanisms asynchronously persist in-memory state without
delaying foreground transactions.
Review Comment:
+1
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
