Traditional database benchmarks often start after data has been loaded, converted, indexed, and analyzed. For exploratory work, that excludes the first cost the user experiences. NoDB’s strongest contribution is therefore not “SQL over CSV.” It changes the metric from query time to data-to-query time.
The problem NoDB reframed
Suppose an analyst receives a new 100 GB file and wants three columns for one experiment.
- A traditional workflow pays an ingestion cost before the first answer.
- A raw-data engine begins immediately but may repeatedly pay parsing and conversion costs.
Neither dominates universally. The relevant question is when the cumulative raw-query cost crosses the load-once cost.
traditional total = load + index/statistics + repeated database queries
raw total = repeated scan/parse cost - benefits learned over timeIn plain terms: NoDB removes the entrance fee, not the cost of using the building.
How PostgresRaw avoided repeated work
The paper’s prototype extended PostgreSQL with several cooperating techniques:
- Selective tokenization: locate only the attributes required by the query when possible.
- Selective parsing: convert only required text values into binary types.
- Positional maps: remember attribute positions discovered in previous scans.
- Binary caching: retain converted values so later queries avoid text conversion.
- Adaptive behavior: invest work according to the columns and rows the workload actually touches.
The positional map is especially important for wide rows. To reach a late CSV attribute, a parser normally walks through preceding delimiters. Remembered offsets turn some of that repeated discovery into direct access.
Why the paper was convincing
The evaluation did not rely on one narrow demo. It included a wide-table microbenchmark, TPC-H-scale experiments, and scientific FITS data, with comparisons against conventional loading workflows. This supports the claim that up-front preparation can dominate time to the first useful answer.
The design also acknowledged that raw access must learn. Without positional information and caches, every query would simply repeat expensive parsing.
Where the conclusion stops
Break-even depends on workload length
If the same stable dataset serves thousands of queries, full loading and mature indexes can amortize their entrance fee. NoDB is most compelling when data is fresh, uncertain, short-lived, or queried selectively.
Memory determines the apparent win
Binary conversion is costly, but cached converted values consume memory. A benchmark should sweep cache budgets and report eviction behavior rather than present one favorable setting.
Raw text is not the modern baseline
Columnar formats such as Parquet already store typed values, column boundaries, and metadata. Modern comparisons should separate the NoDB principle—pay as you go—from CSV-specific parsing techniques.
Convenience does not remove governance
Direct querying still needs schema decisions, invalid-row handling, reproducible transformations, access control, and provenance. Delayed loading can defer governance; it does not make governance unnecessary.
A useful modern experiment
Compare the same dataset in CSV, Parquet, and a loaded table. Measure three horizons:
| Horizon | Question |
|---|---|
| First query | How quickly can a user get one valid answer? |
| Short session | What is the total cost of 10–20 exploratory queries? |
| Stable service | Where does loading and indexing break even? |
Track elapsed time, CPU, bytes read, conversion work, memory used by caches, and answer correctness. Change column width, selected-column position, selectivity, and cache budget. The interesting output is the break-even curve, not a single winner.
What lasted
The lasting idea is architectural: preparation does not have to be all-or-nothing. A system can build metadata, indexes, and binary representations incrementally, guided by observed work. That principle appears in external-table engines, lakehouse query systems, automatic materialization, and adaptive indexing even when their storage formats differ from the paper.
Review card
- Data-to-query time includes preparation before the first query.
- Selective tokenization and parsing avoid work for untouched attributes.
- Positional maps remember structure; binary caches remember conversions.
- The decisive variable is the workload’s break-even horizon.
- CSV-specific results should not be generalized directly to columnar formats.
- Pay-as-you-go access postpones some work; it does not erase correctness or governance.
傳統 database benchmark 常從資料完成 load、type conversion、index 與 statistics 之後才開始計時。對 exploratory work 而言，這漏掉了使用者最先承受的成本。NoDB 最重要的貢獻因此不是「CSV 也能下 SQL」，而是把 metric 從 query time 改成 data-to-query time。
NoDB 重新定義的問題
假設 analyst 收到新的 100 GB file，只想先用三個 column 做一個 experiment：
- 傳統流程要先支付 ingestion，之後才拿到第一個答案。
- Raw-data engine 可以立刻開始，但可能在每次 query 重付 parsing 與 conversion。
兩者沒有永遠的贏家。真正的問題是 cumulative raw-query cost 何時超過 load-once cost。
traditional total = load + index/statistics + repeated database queries
raw total = repeated scan/parse cost - benefits learned over time白話來說： NoDB 取消的是入場費，不是把使用成本變成零。
PostgresRaw 如何避免重複工作
Paper prototype 在 PostgreSQL 上加入數個互相配合的機制：
- Selective tokenization： 可以時只定位 query 需要的 attribute。
- Selective parsing： 只把必要 text value 轉成 binary type。
- Positional map： 記住先前 scan 發現的 attribute position。
- Binary cache： 保留 converted value，後續 query 不必再次轉型。
- Adaptive behavior： 按 workload 真正碰到的 column 與 row 投資。
Positional map 對 wide row 特別重要。要讀後段 CSV attribute，parser 通常得一路走過前面的 delimiter；保存 offset 能把部分反覆探索變成較直接的定位。
為什麼這篇 paper 有說服力
Evaluation 不只做單一 demo，而是包含 wide-table microbenchmark、TPC-H 規模 experiment 與 scientific FITS data，並比較 conventional loading workflow。這支持了「up-front preparation 可能主導 first useful answer」的論點。
設計也承認 raw access 必須逐步學習。沒有 positional information 和 cache，每次 query 只會重複昂貴 parsing。
結論的邊界
Break-even 取決於 workload 長度
如果 stable dataset 要服務數千次 query，完整 load 與成熟 index 能攤平入場費。NoDB 最適合新鮮、不確定、短命或只被選擇性查詢的資料。
Memory 會改變看見的優勢
Binary conversion 昂貴，但 cached value 會吃 memory。Benchmark 應掃過不同 cache budget 並報告 eviction，而不是只展示一個有利設定。
Raw text 不是現代唯一 baseline
Parquet 等 columnar format 已保存 typed value、column boundary 與 metadata。現代比較要拆開 NoDB 的 pay-as-you-go 原則，和 CSV-specific parsing technique。
Convenience 不會消除 governance
Direct query 仍需要 schema decision、invalid-row handling、reproducible transformation、access control 與 provenance。延後 loading 可能延後治理，但不會讓治理消失。
一個更適合今天的實驗
用同一 dataset 比較 CSV、Parquet 與 loaded table，觀察三個 horizon：
| Horizon | 問題 |
|---|---|
| First query | 使用者多久拿到第一個正確答案？ |
| Short session | 10–20 次 exploratory query 的總成本？ |
| Stable service | 何時 loading 與 indexing 開始 break even？ |
同時記 elapsed time、CPU、bytes read、conversion work、cache memory 與 answer correctness。改變 column width、selected-column position、selectivity 和 cache budget。真正有價值的輸出是 break-even curve，不是單一 winner。
留下來的核心思想
Preparation 不必是全做或全不做。系統可以依實際 workload 逐步建立 metadata、index 與 binary representation。即使 storage format 已不同，這個原則仍出現在 external-table engine、lakehouse query、automatic materialization 與 adaptive indexing。
複習卡
- Data-to-query time 包含第一個 query 前的準備。
- Selective tokenization／parsing 避免處理沒碰到的 attribute。
- Positional map 記結構；binary cache 記轉型結果。
- 決定勝負的是 workload 的 break-even horizon。
- CSV 結果不能直接套到 columnar format。
- Pay-as-you-go 只是延後部分工作，不會消除 correctness 與 governance。