{"id":"e118ba35-d496-4bbf-9d64-e7f250308baa","arxiv_id":"2411.08203","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A columnar differential cache for lakehouse pipelines reuses overlapping scan fragments and reduces S3 bytes read by up to 30% in preliminary benchmarks.","lead":"This paper describes Bauplan, a data lakehouse platform with a declarative pipeline API, and a differential columnar cache that reuses scanned data across overlapping queries. The cache reportedly cuts object-storage reads by up to 30% on TPC-H and a taxi-data workload, which could speed up iterative data science work.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The conclusion's admission that adding projections over cached tuples is non-deterministic (due to Iceberg row order) undermines the abstract's 'transparent across schemas' claim and the motivating feature-addition workflow.","rationale":"The reader's weakest assumption focused on the unproven equivalence between greedy and optimal cache-element selection. While that is a legitimate theoretical gap, it is not the most load-bearing issue for the paper's central claim. The reported byte-savings are empirical measurements on specific workloads; even if the greedy algorithm is suboptimal, the measured 'up to 30%' reduction is still what was observed. A non-greedy algorithm might achieve more, but that would not invalidate the reported numbers. The more serious concern is the authors' own admission in the conclusion that adding projections to a cached scan results in non-deterministic positional joins. The abstract promises transparency across schemas, and the motivating workflow explicitly includes adding features. If the cache cannot correctly serve a scan with a superset of cached projections, it fails the intended use case, and the byte-savings claim only covers the limited subset of workloads where projections are unchanged or removed. This is an internally acknowledged limitation, not a speculation about missing proof. It directly affects the system's correctness and its applicability to the abstract's stated purpose. The greedy-optimality issue, by contrast, affects only the degree of savings and is secondary. I therefore partially agree with the reader: the cache's design assumptions need scrutiny, but the schema-addition correctness gap is the load-bearing concern. Since the paper already presents its results as preliminary and the limitation is explicitly stated as future work, a conditional verdict remains appropriate; the authors should either fix the positional-join issue or narrow their claims to non-additive projection changes.","tokens_in":7272,"tokens_out":12585,"duration_ms":129950,"concrete_test":"Construct an Iceberg table and run a two-step workload: first scan with projections (c1, c2) and a filter, caching the result; then run the same filter with projections (c1, c2, c3), forcing the cache to combine the cached (c1, c2) fragment with a new S3 read of c3. Compare the output against a non-cached run of the (c1, c2, c3) scan. If the outputs differ in row order or content, the cache is incorrect for projection additions, invalidating the 'transparent across schemas' claim and restricting the byte-savings claim to workloads without added columns.","verdict_should_be":"UNCHANGED","load_bearing_attack":"In Section V (Conclusion), the authors write: 'Iceberg scans do not guarantee row order, making positional joins non-deterministic when a scan adds projections over existing (pre-filtered) tuples.' This is an explicit limitation of the differential cache. Yet the abstract claims the cache 'works transparently across programming languages, schemas and time windows', and the motivating use case is 'adding or removing features'—i.e., changing the projection set. If a user first caches a scan with columns (c1, c2) and later runs the same filter with columns (c1, c2, c3), the system must read the new column from S3 and join it with the cached rows. Without a stable row order or an explicit join key, this positional join is non-deterministic, producing incorrect or unstable results. The benchmarks in Table II only exercise fixed or shrinking projections, so the reported 'up to 30% fewer bytes' does not validate the feature-addition scenario that motivates the system. This is more load-bearing than the greedy-optimality gap in Section III-B: even if the greedy algorithm is suboptimal, the measured byte savings on the tested workloads remain empirically true; the schema-addition flaw, by contrast, threatens the correctness of the cache in the paper's headline use case.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents Bauplan, a declarative pipeline programming model for lakehouse data pre-processing, and a differential columnar cache that treats S3 scans (projections plus filters over Iceberg/Parquet tables) as the unit of caching. Cached fragments are stored as Arrow tables to enable zero-copy sharing and to avoid repeated Parquet-to-Arrow conversion. The paper argues that caching scans rather than exact query results allows reuse across overlapping filters, different projection sets, and multiple languages, and reports preliminary benchmarks on TPC-H (SF1 and SF100) and a NYC taxi workload showing up to 31.2% fewer bytes read than a scan cache. The authors also describe cache invalidation via Iceberg file immutability and position the work against existing SQL caches and pipeline frameworks.","tokens_in":7548,"tokens_out":4675,"duration_ms":50317,"significance":"If the design holds, the differential scan cache is a practical contribution: it targets a real bottleneck (object-storage read volume in iterative data-science workflows), uses open lakehouse formats, and the hand-computed optimal plan for the taxi workload is a useful consistency check. The paper is honest about the preliminary nature of the results and explicitly names a limitation in the conclusion. However, the central claim that the cache works 'transparently across ... schemas' is broader than what the implementation and benchmarks support, and the quantitative evaluation lacks the detail needed to assess robustness.","major_comments":[{"comment":"The conclusion states that 'Iceberg scans do not guarantee row order, making positional joins non-deterministic when a scan adds projections over existing (pre-filtered) tuples.' This directly contradicts the abstract's claim that the cache works 'transparently across programming languages, schemas and time windows' and the motivating scenario of 'adding or removing features' in Section I. The benchmarks in Table II exercise fixed or shrinking projections, so the reported 'up to 30% fewer bytes' does not validate the feature-addition case. Please either describe a correct mechanism for projection expansion (for example, maintaining row identity or a deterministic sort key when combining cached and newly scanned columns) or explicitly restrict the transparency claim to scans whose projection sets are subsets of cached projections. This is load-bearing because feature addition is a headline use case.","section":"Section V and Abstract"},{"comment":"The statement 'a non-greedy algorithm will produce the same scan after the cache' is asserted without proof, and the function compute_cost() is left unspecified. The greedy selection of cache elements directly determines how many bytes must be read from S3, so any suboptimality would weaken the byte-savings claims in Table II. Please define compute_cost(), prove the optimality claim, or replace it with a systematic comparison of the greedy selection against exhaustive search on the benchmark workloads. The hand-computed optimal check for the taxi workload is a good start but should be extended and described as a method rather than a one-off verification.","section":"Section III-B, Listing 3"},{"comment":"The benchmark methodology is under-specified. The paper does not report error bars, the number of repeated runs, the cache warm-up protocol, the hardware used for the Table II runs, or the implementation details of the result-cache and scan-cache baselines (for example, whether they share the same Arrow-based storage as the proposed cache). Because the central quantitative claim is 'up to 30% fewer bytes' on S3 reads, these details are necessary for reproducibility and for assessing whether the measured savings are stable. Please provide the missing experimental protocol and variability measures.","section":"Section III-C, Table II"}],"minor_comments":[{"comment":"The columns list contains a missing quote: 'columns=[\"c1, \"c2\", \"c3\"]' should be 'columns=[\"c1\", \"c2\", \"c3\"]'.","section":"Listing 1"},{"comment":"The text says 'queries in the TCP are only mildly overlapping in semantics'; this should be 'TPC-H' (or 'TPC') rather than 'TCP'.","section":"Section III-C"},{"comment":"The caption refers to the 'control plain' sending a physical plan; this should be 'control plane'.","section":"Figure 2 caption"},{"comment":"The phrase 'object storage latency disrupt the feedback loop' should be 'object storage latency disrupts the feedback loop'.","section":"Section V"},{"comment":"The caption has an extra period and colon: 'left to right).:' should be cleaned up to 'left to right).'.","section":"Figure 4 caption"},{"comment":"Consider clarifying in the text that the 'columns' parameter in Listing 1 is a projection list and that filters are pushed down to the scan; this would help readers who are not familiar with the Bauplan API.","section":"Section II"}],"recommendation":"major_revision","confidential_remarks":"To the editor: This is an industrial systems paper with a practical motivation and several well-chosen design elements (scan-level caching, Arrow representation, Iceberg-based invalidation). The main concern is the gap between the advertised schema-transparency and the disclosed positional-join limitation, which affects the paper's headline use case. The evaluation is also quite preliminary for a journal-level claim. I believe a major revision that sharpens the claims, details the benchmark methodology, and either fixes or explicitly scopes the projection-expansion behavior would be appropriate. The paper may ultimately be better suited to a workshop or short-paper venue, but the ideas are worth developing further."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the differential cache is a sensible reapplication of semantic caching to a lakehouse/FaaS context, and the 30% byte-savings figure is plausible for overlapping scans. But the paper's own conclusion admits that adding projections over cached tuples is non-deterministic (Iceberg row order), which undercuts the 'transparent across schemas' claim and the feature-addition workflow in the abstract. The reader's worry about greedy selection is real but secondary.\n\nWhat's actually new: the combination of declarative FaaS with a columnar Arrow cache over Iceberg/Parquet, plus free invalidation via file immutability. The hand-computed optimal plan for the NYC taxi workload is a good consistency check. They cite prior semantic caching work honestly (Dar et al., Schmidt et al., MotherDuck) and the benchmark code is available. That counts for something.\n\nSoft spots: the stress-test issue is load-bearing. Section V says positional joins become non-deterministic when a scan adds projections over cached tuples. That's exactly the 'adding features' scenario. The benchmarks only exercise fixed or shrinking projections, so the 30% figure does not validate the motivating case. The fix is straightforward (cache row IDs or a join key, or read the new column from S3 and merge deterministically), but as written the claim is too strong. The greedy-optimality gap in Section III-B is less severe: even if greedy is suboptimal, the measured savings hold for the tested workloads, but the assertion needs proof or a note. Minor points: no error bars on Table II, and compute_cost is left unspecified.\n\nWho this is for: practitioners building lakehouse pre-processing tools, and researchers studying caching for columnar cloud systems. It deserves a serious referee—the core idea is worth a short paper and the flaw is fixable. Recommended outcome: major/minor revision, ask them to address the schema-addition determinism and either fix the implementation or soften the abstract.","headline":"A plausible semantic-caching reapplication with a real 30% byte-savings result, but the schema-addition determinism issue undercuts the headline 'transparent across schemas' claim.","tokens_in":8034,"tokens_out":2455,"would_cite":false,"duration_ms":24748,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A differential cache that treats S3 scans as reusable columnar fragments lets data pre-processing pipelines skip redundant reads, saving up to 30 percent of bytes read from object storage on overlapping workloads.","keywords":["data pre-processing","differential cache","lakehouse","object storage","columnar cache","Apache Arrow","Apache Iceberg","scan caching"],"falsifier":"Find a workload (e.g., overlapping but non-nested date filters on the NYC taxi table) where greedy cache selection reads more bytes from S3 than an exhaustive search over cache subsets; or instrument the cache to show that on the taxi workload the actual bytes read exceed the hand-computed optimal 1.171 GB.","tokens_in":7108,"feed_emoji":"⚡","tokens_out":5843,"duration_ms":55523,"temperature":0.7,"pith_summary":"Data pre-processing pipelines rarely repeat the same query twice, but their scans overlap: a data scientist might add a column, shorten a time window, or switch from Python to SQL while reading the same base table. This paper argues that such overlapping scans should be the unit of caching, rather than exact query results or exact file reads. It introduces Bauplan, a declarative, FaaS-style pipeline model for lakehouses, and a differential cache that stores scan fragments as Arrow tables and reassembles them with UNIONs. On TPC-H and a NYC taxi workload, the cache reads up to 30 percent fewer bytes than exact result or scan caches, with hand-verified optimality on the taxi case. If right, this gives data scientists the fast iteration loop they currently lack without changing their code.","feed_headline":"Differential cache cuts lakehouse data reads by up to 30%","feed_subtitle":"Reusing overlapping columnar scans means changing features or time windows no longer forces a full re-read.","key_machinery":"The central object is the scan: a request over a named Iceberg table for a set of columns (projection) and a row filter, executed as range-byte reads over Parquet files. The cache stores completed scans as Arrow tables, allowing zero-copy views and cheap UNION-based reassembly; a greedy algorithm (with an unspecified cost function compute_cost()) selects cached fragments to minimize the remaining scan, and Iceberg's file immutability makes invalidation free. This machinery carries the argument because every claimed saving derives from reusing such fragments across workloads.","core_discovery":"The central claim is that caching 'scans' — the projection-and-filter expressions that map to byte-range reads over immutable Parquet files in an Iceberg table — rather than caching materialized query outputs, unlocks reuse across the messy, partially overlapping queries typical of data pre-processing. The paper's design stores each scan's result as an Arrow table, so later scans can be answered by taking a UNION of cached fragments plus only the missing range from object storage. Because cached entries are keyed to immutable files with pointers to original S3 objects, invalidation is deterministic and free. The reported evidence is that this differential, columnar cache reduces bytes read from S3 by 17–31 percent across TPC-H scale factors and the motivating workload, and that on the NYC taxi scenario the achieved savings match a hand-computed optimal caching plan.","pith_inferences":["The magnitude of the saving is workload-dependent: workloads whose scans are disjoint would see no benefit, so the 30 percent figure is a property of iterated, overlapping pre-processing, not of all lakehouse queries.","The same differential-cache idea could be ported to other open formats (e.g., Delta Lake) provided they expose immutable file lists and a way to map filters to files.","Because the cost function compute_cost() is left unspecified, the greedy algorithm's practical behavior may depend on whether scan sizes can be estimated accurately from Parquet metadata; a natural extension is to compare greedy versus exhaustive cache selection on synthetic filter sets.","The hand-verified optimality on the NYC taxi workload suggests the cache may already be near-optimal on realistic filter patterns, but the paper's evidence is preliminary (three workloads), not a general bound."],"forward_implications":["Data scientists can add or drop features, change libraries, or shift time windows without triggering a full re-read of the base table when the data is already cached.","The same cache serves both SQL and Python pipelines, because cache hits are keyed to logical scans rather than to a particular language or runtime.","Since cache invalidation comes from Iceberg's immutable file pointers, table updates cannot silently serve stale data.","If the 30 percent saving holds in production, iterative pre-processing workloads spend correspondingly less time waiting on object storage, which is the dominant latency in lakehouse pipelines."],"supporting_citations":[{"why":"Provides the predicate-caching baseline for cloud warehouses against which the paper compares its differential cache.","marker":"[16]"},{"why":"Supplies the open columnar format whose Parquet files are the physical units of the scans the cache reuses.","marker":"[10]"},{"why":"Provides the open table format whose immutable file pointers make cache invalidation deterministic and free.","marker":"[11]"},{"why":"Defines the in-memory columnar representation the cache stores, enabling zero-copy views and avoiding re-serialization.","marker":"[15]"},{"why":"Survey evidence that machine-learning workflows repeatedly access the same data assets, motivating scans as the primary cacheable object.","marker":"[17]"},{"why":"Nearest related work on differential storage; the paper contrasts its SQL-bound design with the language-agnostic lakehouse approach.","marker":"[22]"}],"fun_headline_variants":["Caching scans, not query results, cuts S3 reads by 31%","FaaS and Furious: cache scans, not outputs, for faster data prep","Differential scan cache reuses overlapping reads to cut S3 traffic","Save up to 31% on S3 reads by caching scans, not answers","Scan caching for lakehouse: reuse filtered reads, skip full re-fetch"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire saving rests on the unproven assumption that greedily applying cached fragments one at a time leaves the same remaining scan as an optimal selection would, and that compute_cost() accurately measures scan cost.","fun_headline_variants_meta":{"raw":{"variants":["Caching scans, not query results, cuts S3 reads by 31%","FaaS and Furious: cache scans, not outputs, for faster data prep","Differential scan cache reuses overlapping reads to cut S3 traffic","Save up to 31% on S3 reads by caching scans, not answers","Scan caching for lakehouse: reuse filtered reads, skip full re-fetch"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000314,"raw_usage":{"total_tokens":1717,"prompt_tokens":813,"completion_tokens":904,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":429,"completion_tokens_details":{"reasoning_tokens":802}},"tokens_in":429,"tokens_out":904,"duration_ms":9158,"temperature":1.0,"reasoning_tokens":802,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T21:51:00.266037+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Find a workload (e.g., overlapping but non-nested date filters on the NYC taxi table) where greedy cache selection reads more bytes from S3 than an exhaustive search over cache subsets; or instrument the cache to show that on the taxi workload the actual bytes read exceed the hand-computed optimal 1.171 GB.","supporting_citations":[{"cited_title":"Parquet,","cited_arxiv_id":null,"evidence_quote":"Supplies the open columnar format whose Parquet files are the physical units of the scans the cache reuses."},{"cited_title":"Iceberg,","cited_arxiv_id":null,"evidence_quote":"Provides the open table format whose immutable file pointers make cache invalidation deterministic and free."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the in-memory columnar representation the cache stores, enabling zero-copy views and avoiding re-serialization."},{"cited_title":"How Developers Iterate on Machine Learning Workflows -- A Survey of the Applied Machine Learning Literature","cited_arxiv_id":"1803.10311","evidence_quote":"Survey evidence that machine-learning workflows repeatedly access the same data assets, motivating scans as the primary cacheable object."},{"cited_title":"Differential storage: A key building block for a duckdb-based data warehouse,","cited_arxiv_id":null,"evidence_quote":"Nearest related work on differential storage; the paper contrasts its SQL-bound design with the language-agnostic lakehouse approach."}],"review_version":1}