Server Performance
Some schemes report only throughput or only server time; the missing metric is derived where possible (throughput = DB size / server time). Derived values are shown with hatched bars.
Linear Schemes
Group 1a, 1b, and 2a schemes scan the full database per query — server cost is O(N) and throughput is bounded by memory bandwidth (~10–14 GB/s/core).
A note on the throughput metric in PIR literature
“Throughput” in PIR literature means DB scan rate (GB/s = DB size ÷ server time) — not queries/sec. For schemes with O(N) server work (Groups 1a, 1b, some 2a), this is bounded by memory bandwidth (~10–14 GB/s/core). Only Respire explicitly defines throughput as “ratio of the database size to the server’s computation time” (Table 1 caption); all other schemes report MB/s or GB/s values consistent with this definition without stating it.
Exception — XPIR (2016): XPIR defines “PIR processing throughput” as the rate of homomorphic absorption operations (bits/s through crypto ops), and “user-perceived throughput” as end-to-end including network transfer. Neither is simply DB size ÷ server time. XPIR throughput values in our charts use the standard definition for comparability.
Exception — SealPIR (2018): SealPIR reports throughput as requests/second (~7 req/s concurrent client saturation), not DB scan rate.
Sublinear Schemes
Group 2b schemes (Piano, Plinko, RMS24) have O(√N) server work per query — the server makes √N point lookups rather than scanning the full DB. The standard DB-scan-rate throughput metric is not meaningful here; instead we show queries per second (1 ÷ server time).