Hardware Requirements

Hardware Requirements

MemCP requires a platform supported by Go 1.24. The native JIT currently targets x86-64; the interpreter remains the compatibility path where JIT emission is not available.

Capacity depends on compressed column size, hot working set, indexes, delta volume, query intermediates, concurrency, durability mode, and background rebuilds. Do not size RAM from raw MySQL disk size alone.

By default the overall cache budget is 50% of physical RAM and the reloadable persisted-data budget is 30%; exact byte overrides are available. Leave memory for the operating system, filesystem/object-store clients, connections, query work, and colocated services. MemCP also responds to system-wide memory pressure.

Fast local storage improves cold-column reload, WAL, rebuild, import, and restart time. safe durability latency depends heavily on fsync behavior. S3 and Ceph add network and service latency. More CPU cores help independent shards and branches, but memory bandwidth, selectivity, shard count, and nested fanout limit scaling.

Published hardware claims must follow Performance Measurement. Historical benchmarks that returned only HTTP 401/non-2xx responses are not SQL throughput measurements. They are retained below as raw project history, explicitly separated from product evidence.

Capacity-planning procedure

1. Import or generate a representative dataset rather than extrapolating only from source database files.
2. Run the real query/write mix long enough to create normal shards, compression formats, indexes, and caches.
3. Record resident bytes, persisted bytes, index/computed-column memory, delta growth, peak query memory, and cold-reload latency.
4. Exercise concurrent users, rebuilds, backups, and remote-backend outages.
5. Restart and measure WAL replay/reload time; verify results after recovery.
6. Add growth and failure headroom before selecting production limits.

Platform profiles

Small x86-64 or ARM systems can run the interpreter and are useful for development, edge workloads, or reconstructible datasets, but available RAM and storage endurance usually dominate. Server-class x86-64 systems can use the native JIT and more parallel shards; prefer balanced memory channels and NUMA-aware capacity over core count alone. Fast NVMe matters for safe commit latency, cold reload, and rebuild throughput, while S3/Ceph deployments depend on network consistency and backend service limits.

MemCP has historically been exercised on AMD Ryzen systems, HPE Superdome-class SMP hardware and Raspberry Pi 3/4 devices. That breadth illustrates the portability goal, not a current certification matrix. Raspberry Pi deployments should account for limited RAM, slower storage and flash endurance. For reconstructible data, sloppy's normally 15-minute compressed rebuild cycle avoids a continuously synchronized WAL stream and can reduce SD-card write amplification. Irreplaceable data must remain on safe storage; use more durable media rather than weakening its guarantee merely to protect an SD card.

Historical measurements

Earlier wiki revisions published the following ApacheBench runs. They used different hosts, networks, authentication and query paths, so they cannot be compared with one another.

The same revisions described an approximately 8 MiB base process and suggested that one particular 5 GiB MySQL dataset compressed to roughly 1 GiB, then multiplied that by three for working-set headroom. Those figures are retained as the origin of the old sizing advice, not as general requirements: process/runtime size has changed and MySQL disk bytes do not predict MemCP RAM without schema, cardinality, indexes, delta state and query intermediates.

Host/run	Command and result	Latency percentiles (ms)
AMD Ryzen 9 7900X3D, Gigabit network	ab -n 1000000 -c 1000 http://192.168.178.108:4321/sql/test/select%20*%20from%20a 48.842 s; 20,474.09 requests/s; 1,000,000 non-2xx responses; 12-byte bodies	p50 46; p66 52; p75 57; p80 61; p90 73; p95 87; p98 107; p99 122; max 287
Raspberry Pi 3, 100 Mbit/s network	ab -n 1000000 -c 1000 http://192.168.178.73:4321/sql/test/select%20*%20from%20a 1,079.876 s; 926.03 requests/s; 1,000,000 non-2xx responses; 12-byte bodies	p50 818; p66 1,195; p75 1,489; p80 1,612; p90 1,956; p95 2,425; p98 2,920; p99 3,348; max 9,758
Raspberry Pi 4, authenticated SELECT 1	ab -n 10000 -c 600 -A root:admin http://192.168.178.189:4321/sql/oppelbi/select%201 23.173 s; 431.54 requests/s; zero failed requests; 9-byte bodies	p50 1,110; p66 1,572; p75 1,902; p80 2,143; p90 2,847; p95 3,511; p98 4,329; p99 4,866; max 8,908

The Ryzen and Raspberry Pi 3 runs measured fast error handling, not SQL execution. The Raspberry Pi 4 run authenticated and executed a minimal query, but still lacks commit/build, server CPU and memory samples, warm-up policy and repeated trials. The old claim that Raspberry Pi handled roughly 1,000 requests/s and x86-64 12,000 or more therefore cannot be used as a current cross-platform comparison.

The project still aims for high throughput on both compact edge systems and large multicore machines. Reproduce that claim with a successful authenticated workload, current commit, full command, raw samples and CPU/memory/storage context as described in Performance Measurement.

There is no fixed minimum row count or universal “cores per table” rule. For a tiny workload, scheduling parallel work can cost more than it saves; for a bandwidth-bound scan, extra cores stop helping before CPU is exhausted.