How Permisyn actually performs.
We don't publish capacity claims we haven't verified. Every number on this page came from a real test against production — including the ones that found real limits, which we fixed and documented rather than hid.
Real, separate startup customers — not one script
N independent accounts, each with its own realistic, non-synchronized usage, all running at once
Instead of one org firing a synchronized burst, we registered separate real accounts and had each one make its own independent, realistically-spaced calls at the same time — the actual shape of "multiple startups using this simultaneously," not an artificial single-source spike.
At 38 simultaneous, every customer saw some slowdown (not a hard outage for anyone) and full recovery was immediate afterward. This is the number we run on today, not a one-time temporarily-scaled-up test.
Staged up to find the absolute ceiling
100 → 4,000 concurrent requests, staged deliberately, on temporarily-scaled-up infrastructure
We temporarily scaled the database and compute up and pushed concurrency higher in stages, confirming a clean recovery between each one — not a single lucky spike, a real staged search for where things actually start to strain. This was a deliberate one-time ceiling test, not our everyday running configuration (see the test above for what we actually run today).
4,000 showed real strain — some requests took too long under that exact load. Nothing crashed and nothing went silent: we found the next bottleneck (a connection pool setting), logged it, and documented it. This scale is a fast, reversible upgrade away whenever real traffic actually needs it — not a ceiling we're hiding, and not a cost we carry every day before we need to.
Real application, real end-users — not a dev-tool benchmark
Your app's own background calls, plus real individual end-users, running at the same time
This is the pattern that actually matters if you're embedding Permisyn inside a real product: your app's own automated calls (background jobs, scheduled processing) running alongside real, distinct end-users — each with their own identity via X-Permisyn-User — making their own occasional requests, all at once, not a single synthetic script.
The app's own background traffic and the real end-users saw almost identical latency (p50 ≈ 0.65s, p95 under 1.6s for both) — neither one starved the other. This is what "Permisyn inside your real application" actually looks like under real usage, not a lab number.
Sustained, growing load
608 requests ramping up over ~53 seconds, not arriving all at once
Traffic grew steadily from a light trickle to a sustained peak — the way real usage actually grows, not a single synchronized spike.
Zero missing, latency stayed under 5.4s throughout, infrastructure scaled up smoothly to match demand.
Extreme synchronized burst
250+ requests arriving in the exact same instant — an artificial worst case
We deliberately pushed past realistic usage to find the actual ceiling, not just a comfortable number. This is not how real traffic behaves — real usage is spread across time, even at scale.
Once genuinely oversubscribed, every call still gets a clear, signed response telling the caller to retry — never a crash, never a dropped receipt, never a silent failure.
Have a specific traffic pattern you want us to test before you commit? Ask — we'd rather verify it than guess.
Talk to us about your traffic