600 GB of laboratory data today.
6 TB within a few years.
It needs one working database.
Relational (PostgreSQL)
vs
Graph (RDF triplestore).
Decision: Relational vs Graph (RDF):
+| + | Relational (PostgreSQL) | +Graph (RDF) | +
|---|---|---|
| Average report, today | +~6 seconds | +~1.6 hours | +
| Average report at 6 TB | +~30 seconds | +~12 hours | +
| Hardware at 6 TB | +one ordinary server | +a 14-server cluster | +
| Ontology | +remains accessible with Relational (PostgreSQL) | +|
| + | Relational (PostgreSQL) ✓ recommended |
+ Graph (RDF triplestore) ✗ rejected at scale |
+ + |
|---|---|---|---|
| Average report, todayat 600 GB | +✓about 6 seconds | +✗about 1.6 hours; 3 of 7 tasks need more than a day | +details → | +
| Average report at 6 TBthe 3-year horizon | +✓about 30 seconds | +✗about 12 hours; 5 of 7 tasks need a day or more | +details → | +
| Servers needed todayat 600 GB | +✓one standard server, $10.5k | +✗already two servers with 1.4 TB of memory, $58.7k | +details → | +
| Servers at 6 TB | +✓still one server, $33.6k | +✗a 14-server cluster, $527.7k | +details → | +
| Disk for the same dataat 6 TB | +✓21 TB | +✗91 TB - the graph form stores the same data 4.4x bigger | +details → | +
Bars are to scale within each panel - the blue bar is real, it is just that small. An everyday report that takes hours is a report nobody runs.
+CSV stays exactly where it belongs - the raw archive coming off the instruments (best compression, byte-reproducible). JSON-LD stays the exchange format for sending data between laboratories. Neither is a working database, so neither was a candidate. SQLite is excellent for a single user up to ~600 GB but does not scale to the shared 6 TB horizon.
+And the ontology? It survives intact: semantic, ontology-style access is provided as a virtual layer on top of PostgreSQL (e.g. Ontop OBDA) - the graph view without the graph database's cost.
+Every number shown on the Storage Decision executive summary, traced to the artifact that proves it. All source files are committed in the public repository and regenerate deterministically from seed 20260711. Projection tables carry one row per format x task x scale; "geometric mean" is the same averaging the study's scoring uses.
+Sources: t6 = t6_projected_all_scales.csv · t7 = t7_hardware_all_scales.csv · t1 = t1_storage_footprint.csv · prices = hw_prices.yaml · spec = 10_extrapolation_model.md
+ +| ID | Fact on the page | Exact value | How obtained | Source |
|---|---|---|---|---|
| P1 | "600 GB of laboratory data today" | 600 GB | The laboratory's current operational volume; also the first extrapolation scale of the study (scale_gb = 600). | spec, t6 |
| P2 | "6 TB within a few years" | 6,000 GB | The largest extrapolation scale of the study (scale_gb = 6000), the growth horizon. | spec, t6 |
| ID | Fact on the page | Exact value | How obtained | Source |
|---|---|---|---|---|
| F1 | PostgreSQL, average report today: "~6 seconds" | 5.66 s | Geometric mean of the 7 projected_wall_s values where format = PostgreSQL, scale_gb = 600. | t6 |
| F2 | PostgreSQL, average report at 6 TB: "~30 seconds" | 29.6 s | Geometric mean, format = PostgreSQL, scale_gb = 6000. | t6 |
| F3 | Graph (RDF), average report today: "~1.6 hours" | 5,902 s = 1.64 h | Geometric mean, format = RDF triplestore, scale_gb = 600. | t6 |
| F4 | Graph (RDF), average report at 6 TB: "~12 hours" | 43,157 s = 11.99 h | Geometric mean, format = RDF triplestore, scale_gb = 6000. | t6 |
| F5 | "3 of 7 tasks need more than a day" (RDF, today) | q3 2.1 d · q5 2.8 d · q7 1.9 d | Count of RDF rows at scale_gb = 600 with projected_wall_s > 86,400. | t6 |
| F6 | "5 of 7 tasks need a day or more" (RDF, 6 TB) | q2, q3, q4, q5, q7 | Count of RDF rows at scale_gb = 6000 with projected_wall_s >= 86,400. | t6 |
| ID | Fact on the page | Exact value | How obtained | Source |
|---|---|---|---|---|
| F7 | "one standard server, $10.5k" (PostgreSQL, today) | $10,500 · 1 node | Row format = PostgreSQL, scale_gb = 600: est_cost_usd, nodes; bill of materials in the configuration column. | t7 |
| F8 | "already two servers with 1.4 TB of memory, $58.7k" (RDF, today) | $58,740 · 2 nodes · 1,404.1 GB RAM | Row format = RDF triplestore, scale_gb = 600: est_cost_usd, nodes, ram_gb. | t7 |
| F9 | "still one server, $33.6k" / "one 16-core server with 551 GB RAM" (PostgreSQL, 6 TB) | $33,586 · 1 node · 16 cores · 551.3 GB | Row format = PostgreSQL, scale_gb = 6000: est_cost_usd, nodes, cores, ram_gb. | t7 |
| F10 | "a 14-server cluster, $527.7k" (RDF, 6 TB) | $527,732 · 14 nodes | Row format = RDF triplestore, scale_gb = 6000: est_cost_usd, nodes. | t7 |
| F11 | "July 2026 prices" | as_of 2026-07-11 | Street prices with per-component source URLs recorded in the operator-editable price file. | prices |
| ID | Fact on the page | Exact value | How obtained | Source |
|---|---|---|---|---|
| F12 | "21 TB" disk (PostgreSQL, 6 TB) | 20.855 TB | Row format = PostgreSQL, scale_gb = 6000: disk_tb (includes 30% free-space headroom). | t7 |
| F13 | "91 TB" disk (RDF, 6 TB) | 91.268 TB | Row format = RDF triplestore, scale_gb = 6000: disk_tb. | t7 |
| F14 | "stores the same data 4.4x bigger" | 11.70 / 2.67 = 4.38 | Ratio of the measured working-footprint coefficients vs raw CSV (RDF 11.70x over PostgreSQL 2.67x). | t1 |
| ID | Fact on the page | Exact value | How obtained | Source |
|---|---|---|---|---|
| K1 | "1,000x faster on the average everyday report" | 1,043x today · 1,459x at 6 TB | F3 / F1 = 5,902 / 5.66; F4 / F2 = 43,157 / 29.6. Stated conservatively as 1,000x. | t6 |
| K2 | "$494k saved" (hardware at 6 TB) | $494,146 | F10 - F9 = 527,732 - 33,586. | t7 |
| K3 | "1 vs 14 servers needed at 6 TB" | nodes: 1 vs 14 | nodes column, rows PostgreSQL/6000 and RDF triplestore/6000. | t7 |
| ID | Fact on the page | Exact value | How obtained | Source |
|---|---|---|---|---|
| N1 | "SQLite is excellent for a single user up to ~600 GB" | all 7 tasks OK at 600 GB; q5 = 1.6 h, q7 = 1.5 h at 1.2 TB | SQLite rows in t6: every flag OK at scale_gb = 600; its single-threaded full scans exceed the 1-hour bound from scale_gb = 1200. | t6 |
| N2 | Method behind every projected number | measured 35-cell benchmark | Scaling laws calibrated on the measured corpus; every measured run checksum-validated. Full methodology and measured medians in the interactive study. | full study |
A 141.8 MiB physically plausible CSV corpus (the canonical raw format) was converted into four other storage formats and benchmarked on seven laboratory retrieval scenarios with subprocess-isolated resource metering; results were extrapolated to 600 GB, 1.2 TB and 6 TB. Every measured run validated its rows against canonical results (PostgreSQL cross-validated with SQLite, tolerance 1e-9).
+A 141.8 MiB physically plausible CSV corpus (the canonical raw format) was converted into four other storage formats and benchmarked on seven laboratory retrieval scenarios with subprocess-isolated resource metering; results were extrapolated to 600 GB, 1.2 TB and 6 TB. Every measured run validated its rows against canonical results (PostgreSQL cross-validated with SQLite, tolerance 1e-9). Short on time? The one-page management summary is Storage Decision.
The measurement corpus is simulated: physically plausible models of a Pt-Au LDRD tribology study context at Sandia National Laboratories, generated from a fixed random seed. It contains no experimental measurements and no export-controlled data. Hardware prices cited in the cost model are public street prices retrieved 2026-07-11 (sources in the Hardware & Cost section).
-Related study in the same repository: Foreign-Key Architecture Study.
+Companion pages in the same repository: Storage Decision (one-page executive summary) · Foreign-Key Architecture Study.