Explain the lifecycle of a write operation in a DuckLake-backed table?

Writing to a DuckLake table involves both the actual data (destined for Parquet in object storage) and metadata about that write (destined for DuckLake's SQL-database-backed catalog), coordinated so that a query always sees a consistent view regardless of exactly where a given row's data currently physically resides.

A small transaction's rows get written as inlined records directly into DuckLake's catalog tables rather than immediately becoming a new small Parquet file, while a sufficiently large transaction writes straight to Parquet as usual. Either way, the catalog database (which could be DuckDB, PostgreSQL, or another supported backend) records the updated metadata, current schema, snapshot pointer, and, for inlined data, the actual inlined rows themselves, within a single transaction that inherits the catalog database's own ACID guarantees.

Subsequent queries read a unified logical view combining whatever Parquet files exist with any still-inlined rows for the current snapshot, so the write's data is fully queryable immediately regardless of whether it physically landed in Parquet or stayed inlined; the later consolidation of inlined data into proper Parquet files (via an explicit flush call or a routine checkpoint) is purely a storage-optimization step that happens independently of, and after, the data already being correctly queryable.