| name | edbt-experiments |
| description | Use when designing or auditing EDBT empirical evaluations for database-systems work, covering real workloads and datasets, fair and tuned baselines, honest measurement across realistic scales, reproducible harnesses, and the higher bar of the Experiments & Analysis paper where the measurement itself is the contribution. |
EDBT Experiments
Use this before submission when the evaluation is not yet locked. EDBT reviewers are database-systems
empiricists; the evaluation is where a good idea is won or lost. The organizing principle is
evidence proportional to the claim — the study must measure the thing the paper actually asserts,
on workloads, datasets, and scales a skeptic would accept, against baselines a skeptic would accept.
Evaluation audit
- Match evidence to the claim shape. A claim about latency needs latency measurements under a
realistic workload; a claim about scalability needs runs across a realistic range of sizes/nodes;
a claim about space needs memory/footprint numbers; a claim about accuracy needs a labeled
ground truth. "Faster on a dataset" is not evidence for a scalability claim.
- Use real workloads and datasets, named and sourced (standard benchmarks, real query logs, real
corpora), not a single toy input. Say how the workload was derived.
- Choose fair, tuned baselines, including the strongest current technique and a
simple-but-reasonable alternative, configured with a documented, equal budget. An untuned baseline
is the most common EDBT reviewer objection.
- Measure honestly: report variance across repeated runs, warm/cold state, the metric definition,
and the hardware/cluster configuration. State what you controlled and what you did not.
- Cover the regimes: where the technique helps, where it is neutral, and its overhead or failure
cases — quantified, not asserted.
- Make the harness reproducible (see
edbt-reproducibility): the evaluation should re-run from
the artifact rather than being re-measured from scratch.
Claim-to-evidence design table
| Database claim | Matching evidence | Reject pattern avoided |
|---|
| "Lower query latency" | Latency under a named workload vs. tuned baseline, with variance | "One unnamed dataset, no baseline config" |
| "Scales to large data / many nodes" | Runs across a realistic size/node range | "Only small inputs / single node tested" |
| "Lower space / memory" | Footprint measured under realistic load | "Asymptotic argument, no measurement" |
| "Robust to skew / adversarial input" | Results across skew levels incl. worst case | "Only uniform / benign inputs" |
| "General across engines / settings" | Multiple engines or configurations + explicit limits | "One engine, claimed universal" |
Measurement discipline (database-systems flavor)
[Workload] name it, source it, say how it was derived; prefer real logs / standard benchmarks
[Baseline] the strongest current technique, TUNED, with the configuration documented
[Scale] realistic sizes and node counts; report where behavior changes
[Variance] repeated runs; report spread, not a single best number
[State] warm vs cold, cache effects, and what was controlled
[Environment] hardware, memory, network, engine build/commit — enough to size a reproduction
The Experiments & Analysis paper (a distinct, higher bar)
When the paper's contribution is the study — a benchmarking, repeatability, or comparative
analysis — the methodology is not support, it is the deliverable:
[Subjects] the systems/techniques compared, chosen by a stated, defensible criterion
[Coverage] the workload and parameter space actually spanned, and what was left out and why
[Fairness] every compared system tuned by its own experts' guidance, not just yours
[Repeatability] the harness re-runs the whole comparison from the artifact
[Findings] the analysis, with the surprising or actionable results foregrounded
An Experiments & Analysis paper that tunes only its authors' preferred system, or spans a workload
space too narrow to generalize, fails on its core contribution, not on a side point.
Vignette: evaluating a query-processing operator
Suppose the paper claims an operator lowers straggler time under skew. The matching plan: derive
workloads from real query logs at several skew levels; run the operator and a tuned skew-aware
baseline across 8-128 workers; report straggler time and total latency with variance; measure the
overhead on skew-free workloads to bound the worst case; and state the boundary (very short queries,
undetectable skew) with a measurement — every number traceable to a logged run in the artifact.
Output format
[Evaluation readiness] strong / adequate / weak
[Claim -> evidence map] <claim: workload / metric / scale>
[Baseline fairness] <baseline -> tuned? equal config? documented?>
[Scale + variance] <realistic range tested? variance reported?>
[Regimes] <helps / neutral / cost / failure all measured? yes/no>
[E&A bar (if applicable)] <methodology, coverage, fairness, repeatability adequate?>
[Decision-critical next run] <one experiment to add>
