Performance Tuning & Benchmarks

Baseline

With the default setup — rate-limiting and request logging enabled, as in a normal production deployment — a single Sentinel instance handles roughly 2,000 requests/second on critical endpoints like /v1/challenge and /v1/verify.

Scaling up

More CPU cores help directly; RAM beyond 16 GB gives diminishing returns. For low-to-moderate traffic, the built-in embedded database and KV store are enough — reach for external backends as traffic grows.

Redis

An external Redis or Valkey 7+ instance outperforms the built-in embedded store significantly. Enable it with REDIS_URL — see Databases.

Network Database

A network database offloads database operations from the embedded default and is required for Clustering.

ClickHouse

For high-traffic deployments, offload request logs and analytics to ClickHouse 22.6+ (Enterprise) so they don't compete with the main database for write I/O.

By traffic volume

Low to moderate traffic — the built-in defaults are sufficient.
High traffic — external Redis/Valkey, network database such as PostgreSQL, and ClickHouse all help independently.

Benchmarks

Methodology

For an accurate benchmark of your own deployment:

Disable rate limiting and Autopilot.
Disable request logging — it can reduce throughput by up to 50%.
Set FLOOD_RATE_LIMIT to empty to disable flood protection.

Results

Endpoint	Requests/sec	Avg latency	Max latency	Throughput
`GET /v1/challenge`	5,257.57	1.90ms	52.01ms	5.29MB/s
`POST /v1/verify`	6,321.77	1.58ms	49.77ms	7.99MB/s
`POST /v1/classifier` (10KB text)	931.68	10.73ms	255.08ms	6.03MB/s

Databases — enabling external backends.
Clustering — scaling horizontally across multiple instances.
ENV Variables — FLOOD_RATE_LIMIT and proof-of-work tuning variables.