cs.DBMar 11, 2026
SaveQuerying Everything Everywhere All at Once: Supervaluationism for the Agentic Lakehouse
Organizations: Bauplan Labs New York, USA
Abstract
Agentic analytics is turning the lakehouse into a multi-version system: swarms of (human or AI) producers materialize competing pipelines in data branches, while (human or AI) consumers need answers without knowing the underlying data life-cycle. We demonstrate a new system that answers questions across branches rather than at a single snapshot. Our prototype focuses on a novel query path that evaluates queries under supervaluationary semantics. In the absence of comparable multi-branch querying capabilities in mainstream OLAP systems, we open source the demo code as a concrete baseline for the OLAP community.
Figures & tables
Figure 1. ACME Inc. demo scenario: three agentic pipelines run concurrently on lakehouse branches, producing divergent versions of analytical tables. When a user asks a question, can we answer it without assuming a canonical data representation?
Figure 2. Architecture of the demo system. Agentic pipelines write predictions into isolated data branches of the lakehouse. The UI translates English questions into SQL, then executes them using a modified OLAP engine that evaluates answers across branches under supervaluationary (glut-tolerant) semantics.
| ID | User-facing question | Result type |
| Q1 | How many customers are expected to buy tomorrow? | Number |
| Q2 | How many smartphone shoppers will convert tomorrow? | |
| Q3 | How many customers in the top segments are expected to buy tomorrow? | |
| Q4 | Is tomorrow’s conversion rate above ? | Boolean |
| Q5 | Is customer expected to buy tomorrow? | |
| Q6 | Which customers are expected to buy tomorrow? | List |
Table 1. Sample questions by result type
Figure 3. Speedup of the native engine over the ad hoc strategy as a function of branch count. The JOIN query with window functions (Q3) benefits from shared-table reuse; the boolean query (Q4) achieves near-constant time via short-circuit evaluation.
Appendix figures & tables2 assets
Supplementary material from the paper’s appendix.
Appendix
| Q | Engine | 1 | 2 | 4 | 8 | 16 | 32 | 50 |
|---|---|---|---|---|---|---|---|---|
| Q1 | Ad hoc | 1 | 4 | 5 | 11 | 21 | 41 | 62 |
| Q1 | Native | 3 | 13 | 15 | 25 | 44 | 88 | 136 |
| Q3 | Ad hoc | 288 | 327 | 732 | 1390 | 2537 | 5125 | 7856 |
| Q3 | Native | 366 | 389 | 392 | 412 | 461 | 562 | 657 |
| Q4 | Ad hoc | 4 | 6 | 9 | 19 | 34 | 67 | 103 |
| Q4 | Native | 4 | 5 | 8 | 9 | 11 | 10 | 11 |
Table 2. Median latency (ms) by engine and branch count.
Figure 4. Median latency (ms) vs. number of branches. Left: Q1, both engines scale linearly but the native engine’s unified plan carries coordination overhead (hash-repartitioning for GROUP BY ). Center: Q3, the ad hoc engine scales at ms/branch (recomputing window functions over the shared table), while the native engine stays nearly flat thanks to CTE reuse. Right: Q4, the native engine’s short-circuit optimization achieves near-constant ms latency.