Ory Hydra token revocation latency limits under concurrent requests

Answer to the question

Ory Hydra does not publish a hard, documented upper bound on concurrent revocation throughput for a PostgreSQL backend. In practice, the limit is dictated by PostgreSQL’s row‑level locking and the underlying storage I/O. Under high concurrency, lock contention on the oauth2_access_tokens and oauth2_refresh_tokens tables typically starts to dominate response time once the number of parallel revocation requests exceeds the database’s ability to serialize updates, often around 200–400 concurrent connections on a modest VM, but this varies widely with configuration and hardware.

What we know (confirmed facts)

• Each revocation request updates a token row, acquiring an exclusive row lock.
• PostgreSQL’s MVCC handles concurrent reads well, but frequent updates to the same table lead to lock waits and potential transaction timeouts.
• Hydra’s architecture treats revocation as an atomic operation; there is no built‑in background batch revocation in the current 2.x releases.
• Official Hydra documentation acknowledges potential performance impact but does not prescribe a specific mitigation strategy.

What we don't know (unconfirmed)

• Exact throughput ceilings for a given hardware and PostgreSQL version.
• Whether recent Hydra releases (2.2.x, 2.3.x) have introduced optimisations that change lock contention behaviour.

Practical steps to gauge your own limits

1. Load test: Use k6, wrk, or JMeter to send increasing numbers of simultaneous POST /oauth2/revoke requests. Aim for 50‑step increments up to at least 1,000 concurrent users.
2. Monitor PostgreSQL:
   • SELECT pid, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state = 'active';
   • SELECT locktype, relation::regclass, mode, granted, pid FROM pg_locks WHERE NOT granted;
   • Track pg_stat_user_tables for n_tup_upd and vacuum_count on the token tables.
3. Identify the tipping point: Look for a sharp increase in wait_event counts or average wait times in pg_locks that coincides with a steep rise in overall latency in your load‑test results.
4. Adjust PostgreSQL settings (if needed):
   • Increase max_connections or use a connection pooler like pgbouncer.
   • Tune shared_buffers and work_mem to reduce lock contention.
   • Enable autovacuum aggressively on the token tables to keep MVCC tuples from bloating.
5. Consider architectural changes if the load consistently exceeds your database’s capacity:
   • Implement a revocation queue that batches updates in a background worker.
   • Use a separate write‑optimized store for revocation logs and keep Hydra’s token table read‑only.

What to ask next

To refine the recommendation, please provide your current PostgreSQL version and key configuration values (e.g., max_connections, shared_buffers, work_mem). These details can shift the concurrency threshold where lock waits become critical.

Summary

Hydra’s revocation throughput is bounded by PostgreSQL’s ability to serialize row updates. While no fixed ceiling exists, contention typically becomes noticeable when concurrent revocation requests approach several hundred on typical hardware. The current Hydra 2.x releases do not prescribe a specific mitigation; operators must monitor lock waits and adjust database settings or redesign the revocation flow to batch updates if necessary.