FusionAuth has the following known limits.
When using the Elasticsearch search engine, the maximum number of users returned for any search is 10,000 users. There is an open bug tracking this issue.
You can work around this limit by writing one or more search queries to return less than 10,000 users.
For example, if you needed to pull all of your users, you could query for users with an email address starting with
A, then starting with
B, and so on.
FusionAuth stores most data in a database. Lengths of specific fields are documented in the database schema for your database type. Please download the database schema for your version of FusionAuth to review length limits for a particular column.
Many varchar columns have a length of 191. Why 191? In MySQL when using a
utf8mb4 (4 byte character set) on an indexed column, MySQL limits the usable characters to 191 to account for the overhead of the 4 byte addressing. The InnoDB MySQL engine has a max index length of 767 bytes (for mysql 5.7.9, the earliest version of MySQL which Fusionauth supports). Because we are using
utf8mb4 which allows up to 4 bytes per character, we end up with 767/4 ~ 191, so we set the column length to that.
FusionAuth is API first and every entity can be managed by an API, with one exception: API keys cannot be created or managed via the API.
The only ways to create an API key are:
Use the administrative user interface
[Kickstart](/docs/v1/tech/installation-guide/kickstart) which only works on fresh installations.
However, there is an open GitHub issue to create an [API key management API](https://github.com/FusionAuth/fusionauth-issues/issues/887)
There are a number of default entities which cannot be removed. Additionally, there are limits to modifying these entities.
The Default tenant
The FusionAuth application, which resides in the Default tenant
The Default theme, which is read only
What’s not limited
All other entities, including but not limited to the following, are limited only by the resources of your system: