Clarify benchmark production limits

.gitattributes

@@ -1,5 +1,6 @@
 * text=auto
 *.bicep text eol=lf
+*.csv text eol=lf
 *.css text eol=lf
 *.html text eol=lf
 *.json text eol=lf

README.md

@@ -343,6 +343,9 @@ The measurements show:
   writes produced failures and very high tail latency for both layouts
 - all 14 regional runs rejected a gzip envelope that expanded beyond the
   16 MiB decoded-object limit
+- cold reads and large indexed writes remain too slow for latency-sensitive
+  request paths; production fit depends on warm browser cache hits dominating
+  user activity
 
 The earlier authenticated Chromium evidence remains checked in:
 

docs/BENCHMARKS.md

@@ -253,6 +253,12 @@ ThimbleDB's small-app target.
 
 ## Current recommendation
 
+Most measured cold reads and every large write result exceed normal
+interactive latency targets. Current production use therefore depends on warm
+browser cache hits dominating user activity. Cold storage access should be
+treated as initial loading, recovery, or background work rather than a
+request-critical UI path.
+
 Use snapshots for:
 
 - small and medium collections
@@ -275,6 +281,9 @@ for the corresponding uncovered paths.
 Do not use either current layout for sustained multi-region writes to one
 collection root.
 
+Do not use the current release for latency-sensitive applications that require
+sub-second cold reads or interactive large indexed writes.
+
 ## Limitations
 
 - Azure regions approximate geography and do not represent residential

docs/FAQ.md

@@ -97,6 +97,11 @@ queries, trie scans, and simultaneous multi-region writes exposed clear poor
 fits. These measurements describe specific Cloudflare and Azure runs. They do
 not establish general superiority over another database.
 
+Current cold reads and large indexed writes are too slow for latency-sensitive
+request paths. ThimbleDB is production-credible only where warm browser cache
+hits dominate and cold loading or writes can tolerate substantially higher
+latency.
+
 ## Is it suitable for vibe-coded applications?
 
 It can fit focused applications that use a small number of JSON record types,

docs/TRADEOFFS.md

@@ -18,6 +18,8 @@
   an eligible cold trie point read from four browser requests to one.
 - Unit tests verify that an explicit covered projection can avoid loading the
   full snapshot page and that uncovered fields fall back to full documents.
+- Current regional evidence shows that cold object reads and large indexed
+  writes miss normal interactive latency targets.
 
 ## Not established by the published evidence
 
@@ -72,3 +74,7 @@ Use ThimbleDB for small, mostly idle, read-heavy applications that benefit from
 encrypted browser caching and per-user or per-tenant storage scopes. Do not
 treat it as a general database replacement. Compare it with a managed database
 using the application's real workload before choosing a production data layer.
+
+Production use should assume that warm browser cache hits dominate. Avoid
+request-critical flows that depend on cold object reads or large indexed
+writes.

site/scripts/prepare-assets.mjs

@@ -1,4 +1,9 @@
-import { copyFile, mkdir } from "node:fs/promises";
+import {
+  copyFile,
+  mkdir,
+  readFile,
+  writeFile,
+} from "node:fs/promises";
 import path from "node:path";
 import { fileURLToPath } from "node:url";
 import sharp from "sharp";
@@ -30,9 +35,14 @@ for (const file of [
   "r2-current-layout-multiregion-2026-09-25.json",
   "r2-current-layout-summary-2026-09-25.csv",
 ]) {
-  await copyFile(
+  const source = await readFile(
     path.join(repositoryRoot, "evidence", file),
+    "utf8",
+  );
+  await writeFile(
     path.join(evidenceDirectory, file),
+    source.replaceAll("\r\n", "\n"),
+    "utf8",
   );
 }
 

site/src/pages/index.astro

@@ -479,9 +479,9 @@ const websiteSchema = {
           simultaneous global writes exposed clear limits.
         </p>
         <p class="evidence-note">
-          Tables, accessible graphs, failures, and raw JSON and CSV evidence
-          are published. The results describe this workload, not universal
-          database performance.
+          Cold reads and large writes remain too slow for latency-sensitive
+          request paths. Production fit depends on warm browser cache hits
+          dominating. Tables, graphs, failures, JSON, and CSV are published.
         </p>
         <a class="button dark" href="/benchmarks/">Read the benchmark and limitations <span>→</span></a>
       </div>

site/tests/site.spec.ts

@@ -1,3 +1,4 @@
+import { createHash } from "node:crypto";
 import { expect, test, type Page } from "@playwright/test";
 
 test("homepage presents the product and complete SEO metadata", async ({
@@ -381,6 +382,22 @@ test("benchmark page publishes tables, graphs, and raw evidence", async ({
   expect(csvResponse.headers()["content-type"]).toMatch(
     /text\/csv|application\/octet-stream/,
   );
+  expect(
+    createHash("sha256")
+      .update(await jsonResponse.body())
+      .digest("hex")
+      .toUpperCase(),
+  ).toBe(
+    "EE93073994C8D7917D203865DEC31C433F9D3DF77C56F44AC032904CB6DA0219",
+  );
+  expect(
+    createHash("sha256")
+      .update(await csvResponse.body())
+      .digest("hex")
+      .toUpperCase(),
+  ).toBe(
+    "76210F31306CE6E7BF0E22C67BC498EA593634E08F89AD5A188A0F3D1B526DB9",
+  );
   await assertNoHorizontalOverflow(page);
 });