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.