Deterministic — xyzDB vs PostgreSQL vs MongoDB

Setup. AWS m6a.xlarge (x86-64-v3 / AVX2; bench containers capped to the T6 envelope = 2 vCPU / 8 GB), SSD, scale 1.0 ≈ 150M records, schema Full, shape A. 3 passes, pooled (median ± σ across passes). Engine-exclusive serial runs — never two engine containers at once. Harness run_aws_4engines.sh. verify_golden + content-gate pass bit-for-bit; recall exact.

Parity-fair. Every engine gets its idiomatic fast path (pg covering / mat-view indexes, mongo aggregation). This supersedes the earlier single-run campaign where only xyzDB had the Q4/Q8 rollup — those pre-parity numbers (Q4 ~3,800× etc.) are retired as misleading.

Status. SSD scale-1 3-pass — complete (cold + concurrent + footprint, all 3 passes, golden + content-gate + integrity). HDD scale-1 — complete (x86-v3, same parity campaign; xyz vs pg). Mongo did not complete on HDD — v8.0 and v7.0 both failed to finish the load within 48h under the same parity configuration; reported as not-completed, not omitted.

1.1 Cold queries — P50 pooled (median of 3 passes)

Wins (pooled): xyz 6 · pg 2 · mongo 1.

• xyz wins 6/9 cold (point, aggregate, full-history, top-exposure, overdue, monthly-close) — 1.6× to 3.4× over the runner-up.
• pg wins Q6 and Q9 (recent-payments 1.5×, customer-context 1.3×) — its covering-index / sorted terrain.
• mongo wins Q7 by 1.05× = statistical tie (batch-ingest).

1.2 Concurrent (Phase 3) — pooled P50 / P99 ms (median of 3 passes)

Worst concurrent P99: xyz 8.6 ms · pg 747 ms · mongo 155 ms. Under mixed read + write, xyz holds P99 ≤ 8.6 ms on every query; pg spikes on Q3 (747 ms, mat-view refresh) plus several 11–54 ms; mongo is uniform 42–63 ms. In P50 concurrent xyz wins 6/9 (as cold); in P99 xyz wins all 9 — the predictable-tail moat.

1.3 Load & footprint (pooled, stable across the 3 passes)

xyz wins load (1.26× pg, 9× mongo), RAM and disk simultaneously (disk 2.3× less than pg), and concurrent-tail stability (pg pays 747 ms on Q3 for the mat-view refresh; mongo's refresh runs in minutes).

1.4 Headline (publishable)

On scale-1 (~150M) on real hardware, xyzDB wins latency in 6/9 queries + load + footprint (RAM and disk) + stability, with recall/golden verified bit-for-bit. It concedes Q6/Q9 to pg (covering index) and ties Q7 with mongo.

Note the RAM here (2,073 MiB, the lowest of the three) — the density moat working: this is the paced load + flushregime, the opposite of the agentic bulk-load regime (no flush), where xyzDB's transient peak is much higher. Same engine, footprint adapts to how it is fed.

1.5 HDD — xyzDB vs PostgreSQL (x86-v3)

AWS HDD (/mnt/hdd), scale 1.0 (149.9M records), x86-v3, 2026-07-17/18. Same parity campaign as the SSD 3-pass. Mongo did not complete on HDD: v8.0 and v7.0 both failed to finish the load within 48h under the same parity configuration (document-model aggregation is non-viable on rotational storage at this scale) — reported as not-completed, not omitted. Both completing engines (xyz, pg): verify_golden YES / 0 diffs.

1.5.1 Cold P50 (ms)

1.5.2 Concurrent P50 / P99 (ms)

1.5.3 Resources

1.5.4 Reading — the HDD co-location moat

xyz barely degrades SSD→HDD (Q4 0.30→0.32, Q3 0.72→0.73, Q9 3.83→3.66) while pg's analytical queries collapse on rotational storage (Q2 1.63→100, Q9 2.95→200, Q3 concurrent P99 → 1,581). On cheap cold storage xyz's lead widens to 8/9 cold and a worst-P99 gap of 20 ms vs 3,482 ms. Mongo is non-viable (did not complete the load in 48h; reported not-completed).

1.6 Idle footprint — empty-DB baseline

Measured 2026-06-17, Mac (arm64), Docker, fresh container, empty database — cold start-up cost before any data. Single host, single sample; the order-of-magnitude gaps are the robust signal, not the exact MiB.

xyzdb boots at 17.7 MiB (vs pg 99, mongo 355 — mongo reserves the WiredTiger cache up front). Its working set grows lazily with data; no fixed multi-hundred-MB floor at boot. Strong for edge / many-instance / serverless.

1.7 Density — N memory-agents per box (product regime)

2026-06-21. The experiment that matters is not “one agent serving X GB active” but N memory-agents coexisting — the real agent-memory infra pattern. 1 process/instance per agent (real isolation); agent = one gravity bucket of 8,000 records (~33 MB). Metric: cgroup memory.current per fleet, separating the hard floor (anon + shmem, non-reclaimable) from page-cache file (reclaimable). Mac OrbStack ≈ m5a.xlarge.

Honest reading.The idle hard floor is comparable, not a blowout: xyzdb ~48 MiB/agent vs pg ~57 (~1.2×); total resident 81 vs 130/agent (~1.6×) — not the order of magnitude an “17 MB vs 135 MB” framing suggests. Under traffic xyzdb's anon spikes (full-bucket materialization per query) but it is transient, not a leak — the balloon returns to the OS in ~75 s of calm. Capacity in 16 GiB (m5a.xlarge): xyzdb ~300 agents idle vs pg ~250 (edge ~1.2–1.6×). The real moat is zero-DBA / zero-index + real per-process isolation at a competitive footprint (a dense f32 sidecar — materialize only top-k — is the lever for the transient balloon and the 14–38 ms query latency).

Native harness under benchmarks/native/; raw per-cell artefacts (aws_ssd_* .json/.csv, one set per pass) on the AWS box. Idle footprint and density are Mac (arm64) measurements.