Merge pull request #992 from supertokens/improv/remove-mysql-support

Author: bcbogdan

docs/authentication/enterprise/saml/overview.mdx

@@ -42,7 +42,7 @@ The way this works is that the third-party solution acts as an OAuth 2.0 provide
 - It's an OAuth provider and a `SAML` client.
 This fits with the architecture.
 - For self hosted, it supports PostgreSQL and MySQL amongst [other databases](https://boxyhq.com/docs/jackson/deploy/service#database).
-Self hosted SuperTokens supports PostgreSQL and MySQL as well.
+Self hosted SuperTokens only supports PostgreSQL as a datasource.
 
 `SAML` Jackson provides an HTTP service that you can host yourself or let BoxyHQ manage.
 The HTTP service uses NodeJS, and is embeddable within your NodeJS backend.

docs/deployment/scalability.mdx

@@ -58,24 +58,21 @@ The scale of end users that this can support is in the order of 1-2 million mont
 If you are facing performance issues, here are some tips to help you tune the performance of your SuperTokens setup:
 - If you are self-hosting the SuperTokens core, know that it is stateless and can scale horizontally. You can add more instances of the core service to handle more requests (behind a load balancer).
 - Check which part of the request cycle is slow. Is it the SuperTokens core responding, or is it the backend SDK APIs responding? The performance of the backend SDK API depends mainly on how you have set up your API layer (that integrates with the backend SDK) to perform. You can check which is slow by enabling debug logs in the backend SDK, and then inspecting the timestamps around the core requests. If they sum up to be much less than the total time taken for the request (from the `frontend`'s point of view), then the bottleneck is likely in the backend SDK.
-- If you are self-hosting the SuperTokens core, check if there are any database queries that are too slow. You can do this using debugging tools provided by the PostgreSQL or MySQL databases. If you find a query that's causing issues, please reach out to support.
+- If you are self-hosting the SuperTokens core, check if there are any database queries that are too slow. You can do this using debugging tools provided by the PostgreSQL database. If you find a query that's causing issues, please reach out to support.
 - Check that the compute used to run the backend SDK, the SuperTokens core (in case you are self-hosting it), and the database is sufficient. Using a t3.micro EC2 instance for the core should work well for even 100,000 MAUs. You can check the `CPU` and memory usage of the instances to see if they have maxed out, or if you have run out of `CPU` credits. If they are, you can consider upgrading the instances to more powerful ones.
 - In case you are self-hosting the SuperTokens core, you can tune its performance by setting different values for the following configurations in the configuration.yaml file, or docker `env`:
     - `max_server_pool_size`: Sets the max thread pool size for incoming `http` server requests. Default value is 10.
     - `postgresql_connection_pool_size` (if using psql): Defines the connection pool size to PostgreSQL. Default value is 10.
     - `postgresql_minimum_idle_connections` (if using psql): Minimum number of idle connections to remain active. If not set, minimum idle connections are the same as the connection pool size. By default, this is not set.
     - `postgresql_idle_connection_timeout`: (if using psql): Timeout in milliseconds for the idle connections to close. Default is 60000 MS.
-    - `mysql_connection_pool_size` (if using `mysql`): Defines the connection pool size to MySQL. Default value is 10.
-    - `mysql_minimum_idle_connections` (if using `mysql`): Minimum number of idle connections to remain active. If not set, minimum idle connections are the same as the connection pool size. By default, this is not set.
-    - `mysql_idle_connection_timeout`: (if using `mysql`): Timeout in milliseconds for the idle connections to close. Default is 60000 MS.
 - Check if you have access token blacklisting enabled in the backend SDK. The default is `false`, but if you have it enabled, then it means that every session verification attempt queries the SuperTokens core to check the database. This adds latency to the session verification process and increases the load on the core. If you want to keep this to `true`, consider making it only for non `GET` APIs for your application.
 - You can increase the value of `access_token_validity` in the SuperTokens core. It sets the validity of the access token. Default value is 3,600 seconds (1 hour). The lower this value, the more often the refresh API calls the core, increasing the load on the core.
 
 ---
 
 ## Database 
 
-SuperTokens works with PostgreSQL and MySQL databases, and one instance of the database is enough to handle tens of millions of MAUs.
+SuperTokens works with PostgreSQL databases, and one instance of the database is enough to handle tens of millions of MAUs.
 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).
 
 ---