Built for sensitive data. Measured at scale.
Privacy infrastructure sits on the critical path of your application. Every additional millisecond affects the systems that depend on it. Privacy Vault is benchmarked against real application requests, database workloads and growing token-store sizes — the results below reflect measured configurations, not theoretical capacity estimates.
Benchmark-backed. Single-primary tests. Durability enabled.
Privacy infrastructure sits on the critical path of your application. Every additional millisecond affects the experience of the systems that depend on it. Privacy Vault is benchmarked against real application requests, database workloads and growing token-store sizes. The results below reflect measured configurations, not theoretical capacity estimates.
Our benchmarks are designed to reflect production-relevant conditions rather than isolated in-memory operations.
| Parameter | Configuration |
|---|---|
| Database | PostgreSQL |
| Payload | 256 bytes |
| Network | Separate client and database nodes |
| Infrastructure | Private VPC |
| Durability | Enabled |
| Dataset | 1M–50M tokens |
| Concurrency | Single worker and 64 concurrent workers |
Results are generated from committed benchmark artifacts. Raw JSON results are the source of truth for published metrics. P99 and P99.9 are presented separately where the artifacts provide them; we do not infer one from the other.
What your application actually experiences.
The following measurements represent HTTP end-to-end requests, including the application and database boundary.
| Operation | P50 |
|---|---|
| Detokenize — async audit | 280 µs (0.28 ms) |
| Search — blind index | 340 µs (0.34 ms) |
| Tokenize — async audit | 850 µs (0.85 ms) |
| Detokenize — durable default | 1.45 ms |
| Tokenize — strict durable | 1.88 ms |
Batching increases the durable processing ceiling to approximately 13.4k operations per second per tenant.
The underlying vault, measured independently.
These benchmarks measure AES-256-GCM decryption and an indexed database point read for detokenization, and the corresponding indexed lookup for blind-index search.
Detokenization
| Metric | 1M rows | 20M rows |
|---|---|---|
| P50 — single worker | 130 µs (0.13 ms) | 160 µs (0.16 ms) |
| Throughput — 64 workers | 87,760 /s | 64,596 /s |
| P99.9 — 64 workers | 3.29 ms | 4.70 ms |
Blind-index search
| Metric | 1M rows | 20M rows |
|---|---|---|
| P50 — single worker | 140 µs (0.14 ms) | 140 µs (0.14 ms) |
| Throughput — 64 workers | 53,229 /s | 47,889 /s |
| P99.9 — 64 workers | 5.36 ms | 6.67 ms |
Approximately 95% of vault traffic is read-oriented. Optimizing indexed retrieval and detokenization therefore has a direct impact on the performance of applications using the vault.
One primary. Five dataset sizes.
The ingestion rate remains relatively consistent as the corpus grows. Read throughput changes with the size of the working set and the memory available to the database.
| Tokens | Ingest /s | Detokenize P50 | Detokenize /s | Search /s |
|---|---|---|---|---|
| 1M | 19,939 | 130 µs (0.13 ms) | 87,760 | 53,229 |
| 10M | 19,616 | 190 µs (0.19 ms) | 69,746 | 49,058 |
| 20M | 19,559 | 160 µs (0.16 ms) | 64,596 | 47,889 |
| 30M | 20,109 | 630 µs (0.63 ms) | 45,407 | 41,534 |
| 40M | 17,880 | 940 µs (0.94 ms) | 42,162 | 40,800 |
| 50M | 17,853 | 1.00 ms | 38,617 | 33,525 |
Fifty million tokens on a single PostgreSQL primary. No architectural redesign required for the tested configuration.
Know your infrastructure requirements before you scale.
Measured database storage is approximately 2.92–2.97 KB per token. Memory availability influences how much of the working set can remain readily accessible.
| Reference | Capacity |
|---|---|
| Approximate storage per token | 3 KB |
| Reference RAM-to-corpus ratio | 1.6× |
| 16 GB RAM | 5M tokens |
| 32 GB RAM | 10M tokens |
| 128 GB RAM | 20–30M tokens |
These are benchmark-derived reference points, not universal capacity guarantees. Actual requirements depend on concurrency, query patterns, retention, database configuration and workload distribution.
Reference infrastructure configurations.
Token volume, CPU and RAM reference points derived from the benchmark matrix.
| Token volume | CPU | RAM |
|---|---|---|
| 5M | 2 vCPU | 16 GB |
| 10M | 8 vCPU | 32 GB |
| 20–30M | 32 vCPU | 128 GB |
Actual requirements vary with concurrency, query patterns, retention, database configuration and workload distribution.
OpenBao key backend. A separate boundary. A separate benchmark.
The token store and cryptographic key backend serve different responsibilities and must not be conflated.
The PostgreSQL token store has been measured up to 50M tokens per tenant. The OpenBao transit-key backend has been measured up to 30M keys. We do not claim a measured 50M-key OpenBao deployment. This distinction matters because overall system capacity depends on the performance and sizing of both components.
| Keys | Fill TPS | p50 | p99 | p99.9 |
|---|---|---|---|---|
| 5M | 2,842 | 27.45 ms | 122.17 ms | 189.31 ms |
| 10M | 2,777 | 27.21 ms | 129.34 ms | 202.62 ms |
| 20M | 2,432 | 27.33 ms | 161.41 ms | 493.82 ms |
| 30M | 3,722 | 21.31 ms | 91.90 ms | 145.66 ms |
OpenBao 2.7.2, single server, integrated storage (raft/bbolt), measured at 100 concurrent workers. p99.9 figures reflect raft-snapshot overlap; steady-state phases reach 10–11.4k lookups/s with p99 1.6–39 ms through 20M.
What we measure — and what we don't claim.
We believe engineering claims should be independently verifiable.
What we measure
Application-level latency. Database engine latency. P50, P99 and P99.9 where benchmark artifacts provide them. Concurrent operation throughput. Ingestion throughput. Dataset growth and storage footprint. Restore performance. Error rates across benchmark workloads.
What we don't claim
Theoretical maximum capacity presented as measured performance. Zero latency or unlimited scalability. 50M OpenBao transit keys. 99.9% historical uptime. SOC 2, ISO 27001 or other organizational certifications that we do not hold.
Our position is simple: if we publish a number, there should be evidence behind it.
See it on your own workflow.
Bring one sensitive flow. We will map it to a vault schema live in 30 minutes.