| Recall | mkt-auto | mkt-scale10 |
|---|---|---|
| 0.90 | 145 | 84 |
| 0.95 | 116 | 75 |
| 0.99 | 76 | 63 |
| Recall · clients | mkt-auto | mkt-scale10 |
|---|---|---|
| 0.95 · 1 client | 108 (108) p50 9.07 ms · p95 13.81 ms | 78 (78) p50 13.03 ms · p95 19.70 ms |
| 0.95 · 2 clients (2x of 1 CPUs) | 105 (105) · 1.0× p50 18.94 ms · p95 25.60 ms | 73 (73) · 0.9× p50 27.05 ms · p95 40.19 ms |
| 0.99 · 1 client | 87 (87) p50 11.30 ms · p95 16.85 ms | 65 (65) p50 15.40 ms · p95 24.29 ms |
| 0.99 · 2 clients (2x of 1 CPUs) | 88 (88) · 1.0× p50 22.75 ms · p95 30.29 ms | 63 (63) · 1.0× p50 30.96 ms · p95 46.69 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.977) · mkt-scale10 @0.95: mkt-scale10 (r=0.953) · mkt-auto @0.99: mkt-auto (r=0.992) · mkt-scale10 @0.99: mkt-scale10 (r=0.994)
| mkt-auto | mkt-scale10 | |
|---|---|---|
| @ recall 0.90 | ||
| p50 | 6.65 ms | 12.17 ms |
| p95 | 10.92 ms | 18.28 ms |
| p99 | 13.78 ms | 25.42 ms |
| @ recall 0.95 | ||
| p50 | 8.42 ms | 13.59 ms |
| p95 | 13.01 ms | 20.86 ms |
| p99 | 15.54 ms | 30.07 ms |
| @ recall 0.99 | ||
| p50 | 13.08 ms | 15.72 ms |
| p95 | 18.78 ms | 24.56 ms |
| p99 | 22.01 ms | 35.21 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.
| Instance type | c8g.medium |
| Hostname | ip-172-31-37-199 |
| CPU | unknown (1 vCPU) |
| Memory | 2 GB |
| OS | Ubuntu 26.04.1 LTS |
| Kernel | 7.0.0-1014-aws |
| rekall | 0.1.0 (f31e456 / feature/concurrent-search) |
| PostgreSQL | PostgreSQL 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_prewarm | 1.2 |
| pg_vectorsearch | 0.1.0-dev (97a221a) |
| vector | 0.8.7 |
| k | 10 |
| runs | 3 |
| warmup | 500 |
| num_queries | 10000 |
| S3 archive | s3://rekall-bench/runs/cohere-1m/2026-10-09/c8g.medium-074751/ |
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
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