← all runs

Cohere-1M — 2026-10-08

c8g.medium · peak recall 0.9998 @ 35 QPS
“cost-aware rerank_pool scale sweep (pg_vectorsearch PR #252, 938d068)”

QPS at recall

Recallmkt-automkt-scale10mkt-scale15mkt-scale25
0.9017586116163
0.9514177101137
0.9968657878

Throughput under load

Recall · clientsmkt-automkt-scale10mkt-scale15mkt-scale25
0.95 · 1 client147 (147)
p50 6.55 ms · p95 10.37 ms
79 (79)
p50 12.78 ms · p95 19.50 ms
108 (108)
p50 9.34 ms · p95 13.73 ms
134 (134)
p50 7.25 ms · p95 11.35 ms
0.95 · 2 clients (2x of 1 CPUs)168 (168) · 1.1×
p50 11.64 ms · p95 17.68 ms
74 (74) · 0.9×
p50 26.70 ms · p95 39.13 ms
100 (100) · 0.9×
p50 19.66 ms · p95 28.69 ms
142 (142) · 1.1×
p50 13.75 ms · p95 20.73 ms
0.99 · 1 client95 (95)
p50 10.19 ms · p95 14.85 ms
66 (66)
p50 15.05 ms · p95 23.73 ms
85 (85)
p50 11.51 ms · p95 17.79 ms
88 (88)
p50 11.02 ms · p95 16.17 ms
0.99 · 2 clients (2x of 1 CPUs)132 (132) · 1.4×
p50 14.42 ms · p95 22.29 ms
62 (62) · 0.9×
p50 31.65 ms · p95 48.00 ms
81 (81) · 1.0×
p50 24.14 ms · p95 35.30 ms
113 (113) · 1.3×
p50 17.07 ms · p95 25.14 ms

Each configuration is measured at its operating point for the target: its fastest sweep point whose recall reaches it. Values are measured there, not interpolated, so the recall can be above the target. Each cell is wall-clock QPS over the whole run, then in parentheses the throughput while every client is busy, which leaves out the drain at the end, and below them the p50 and p95 query latency over all clients. With more than one client, N× is the speedup: wall-clock QPS over the same configuration's single-client wall-clock QPS at that target. Ideal scaling matches the client count until the host's CPUs saturate, after which it flattens. Clients are concurrent connections from rekall, and CPU counts are the rekall host's. Wall-clock QPS includes rekall's own work between queries, so the 1-client row reads a little below QPS at recall, which comes from query latency. Recall is distance-based (ann-benchmarks, tie-aware).

Measured on config — mkt-auto @0.95: mkt-auto (r=0.967) · mkt-scale10 @0.95: mkt-scale10 (r=0.953) · mkt-scale15 @0.95: mkt-scale15 (r=0.951) · mkt-scale25 @0.95: mkt-scale25 (r=0.973) · mkt-auto @0.99: mkt-auto (r=0.993) · mkt-scale10 @0.99: mkt-scale10 (r=0.994) · mkt-scale15 @0.99: mkt-scale15 (r=0.993) · mkt-scale25 @0.99: mkt-scale25 (r=0.996)

Latency at recall

mkt-automkt-scale10mkt-scale15mkt-scale25
@ recall 0.90
p505.47 ms11.85 ms8.76 ms5.88 ms
p959.08 ms17.72 ms12.77 ms9.59 ms
p9911.11 ms24.82 ms17.38 ms11.72 ms
@ recall 0.95
p506.84 ms13.28 ms9.92 ms7.06 ms
p9510.74 ms20.29 ms14.81 ms11.14 ms
p9913.08 ms29.59 ms20.50 ms13.69 ms
@ recall 0.99
p5014.45 ms15.40 ms12.64 ms12.58 ms
p9518.96 ms23.92 ms18.71 ms17.28 ms
p9922.08 ms34.58 ms23.01 ms20.35 ms

All values are taken at exactly the stated recall: each configuration's own sweep is log-interpolated between its two surrounding measured points (measured values are used verbatim on an exact hit) and the best configuration at that recall is shown — values are never interpolated across different configurations. “—” means no single sweep spans that recall; nothing is extrapolated. Recall is distance-based (ann-benchmarks, tie-aware). Insert/update/delete workloads are not measured.

Plots

Pareto svg  ·  Distance-recall svg  ·  Per-config svg
paretodistance-recall

Host

Instance typec8g.medium
Hostnameip-172-31-37-199
CPUunknown (1 vCPU)
Memory2 GB
OSUbuntu 26.04.1 LTS
Kernel7.0.0-1014-aws

Versions

rekall0.1.0 (f31e456 / feature/concurrent-search)
PostgreSQLPostgreSQL 18.6 (Ubuntu 18.6-1.pgdg26.04+2) on aarch64-unknown-linux-gnu, compiled by gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0, 64-bit
pg_prewarm1.2
pg_vectorsearch0.1.0-dev (938d068)
vector0.8.7

Search

k10
runs3
warmup500
num_queries10000
S3 archives3://rekall-bench/runs/cohere-1m/2026-10-08/c8g.medium-203259/
Instance settings (observed)
instance type          c8g.medium
vCPU (observed)        1
memory (observed)      1.8 GiB
cpu model              unknown
kernel                 7.0.0-1014-aws
data directory         /var/lib/postgresql/18/main
mount point            /
filesystem             ext4
media                  ebs
device                 nvme0n1
device size            107 GB
ebs volume             vol-04865ecb7ba623cf5
ebs volume type        gp3
provisioned IOPS       3000
provisioned throughput 125 MB/s
io scheduler           mq-deadline
nr_requests            126
read_ahead_kb          128
PostgreSQL settings
checkpoint_completion_target = 0.9
cluster_name = 18/main
data_directory = /var/lib/postgresql/18/main
effective_cache_size = 1 GB
effective_io_concurrency = 200
huge_pages = try
jit = off
maintenance_io_concurrency = 200
maintenance_work_mem = 384 MB
max_connections = 52
max_parallel_maintenance_workers = 1
max_parallel_workers = 1
max_wal_size = 4 GB
random_page_cost = 1.1
server_version = 18.6 (Ubuntu 18.6-1.pgdg26.04+2)
shared_buffers = 512 MB
wal_level = replica
work_mem = 16 MB