Skip to main content

Scalability

SuperTokens users and tenants scalability#

SuperTokens can handle 10s of millions of users and tenants (organizations). In fact, you can even make one tenant per user and it would work well. For most operations, the database structure and queries are designed in a way to be easily partitioned based on tenants and users. This means that as the number of tenants scale, it does not affect performance on most operations on a per tenant scale, and as the number of users scale, it does not affect performance on most operations on a per user scale.

SuperTokens core scalability#

important

If you are using our managed service, the SuperTokens core is fully managed by us, and you don't have to worry about scaling it. This section is for those who are self-hosting the SuperTokens core service.

The SuperTokens core service is designed to be horizontally scalable. This means that you can add more instances of the core service to handle more requests. The core service is also stateless, which means that you can add or remove instances without worrying about the state of the system.

The core service is designed to be able to handle a high number of requests per second (RPS). The exact number of RPS that the core service can handle depends on the hardware that you are using, but in general, the core service is designed to be able to handle a large number of requests.

For example, the average latency of requests is ~40 milliseconds at 100-150 requests per second (6,000-10,000 RPM) as you can see below. The compute deployed is 6 instances of the SuperTokens core service, each on a t3.micro EC2 instance behind a round robin load balancer. The CPU usage of each instance is around 10%.

The scale of number of end users that this can support is in the older of 1-2 million monthly active users, with a total user count of several millions more.

Average latency over 1 day#

Number of requests per minute over 1 day#

Database scalability#

SuperTokens works with PSQL and MySQL databases and one instance of the database is enough to handle 10s of millions of MAUs, easily. For example, a database with 1 million users would occupy ~ 1.5 GB of disk space (assuming you add minimal custom metadata to the user object).

Backend SDK scalability#

The backend SDK does not store any information on its own. It's just a "big middleware" between the frontend requests and the supertokens core. As such, its scalabillity depends entirely on the scalability of your API layer into which our backend SDK has been integrated.

Session verification scalability#

The access token is a JWT, and so, they are verified by our backend SDK without any network requests, making them very fast, and very scalable. The refresh token is verified by the core service, and so, the scalability of session refresh requests depends on the scalability of the core service, however, session refreshes would be a relatively rare compared to access token verification.

Need help?#

See the section on tuning SuperTokens to get tips on how to improve performance.