AWS Documentation » Amazon Relational Database Service (RDS) » User Guide » Limits for Amazon RDS

Limits for Amazon RDS

This topic describes the resource limits and naming constraints for Amazon RDS.

Limits in Amazon RDS

Each AWS account has limits, for each AWS Region, on the number of Amazon RDS resources that can be created. Once a limit for a resource has been reached, additional calls to create that resource fail with an exception.

The following table lists the resources and their limits per region.

Resource	Default Limit
Clusters	40
Cluster parameter groups	50
Cross-region snapshots copy requests	5
DB Instances	40
Event subscriptions	20
Manual snapshots	100
Manual cluster snapshots	100
Option groups	20
Parameter groups	50
Read replicas per master	5
Reserved instances	40
Rules per DB security group	20
Rules per VPC security group	50 inbound 50 outbound
DB Security groups	25
VPC Security groups	5
Subnet groups	50
Subnets per subnet group	20
Tags per resource	50
Total storage for all DB instances	100 TiB

Note

By default, you can have up to a total of 40 Amazon RDS DB instances. Of those 40, up to 10 can be Oracle or SQL Server DB instances under the "License Included" model. All 40 can be MySQL, MariaDB, PostgreSQL, or Oracle under the "BYOL" model. If your application requires more DB instances, you can request additional DB instances via this request form Request RDS DB instance limit.

Backups managed by AWS Backup are considered manual snapshots for the manual snapshot limit. For information about AWS Backup, see the AWS Backup Developer Guide.

Naming Constraints in Amazon RDS

The following table describes naming constraints in Amazon RDS.

DB instance identifier	Must contain 1 to 63 alphanumeric characters or hyphens. First character must be a letter. Cannot end with a hyphen or contain two consecutive hyphens. Must be unique for all DB instances per AWS account, per region.
Database name	Database name constraints differ for each database engine. MySQL and MariaDB Must contain 1 to 64 alphanumeric characters. Cannot be a word reserved by the database engine. Oracle Cannot be longer than 8 characters. PostgreSQL Must contain 1 to 63 alphanumeric characters. Must begin with a letter or an underscore. Subsequent characters can be letters, underscores, or digits (0-9). Cannot be a word reserved by the database engine. SQL Server Not applicable. For SQL Server, you create your databases after you create your DB instance. Database names follow the usual SQL Server naming rules.
Master user name	Master user name constraints differ for each database engine. MariaDB Must contain 1 to 16 alphanumeric characters. Cannot be a word reserved by the database engine. MySQL Must contain 1 to 16 alphanumeric characters. First character must be a letter. Cannot be a word reserved by the database engine. Oracle Must contain 1 to 30 alphanumeric characters. First character must be a letter. Cannot be a word reserved by the database engine. PostgreSQL Must contain 1 to 63 alphanumeric characters. First character must be a letter. Cannot be a word reserved by the database engine. SQL Server Must contain 1 to 64 alphanumeric characters. First character must be a letter. Cannot be a word reserved by the database engine.
Master password	The password for the master database user can be any printable ASCII character except "/", """, or "@". Master password constraints differ for each database engine. MySQL and MariaDB Must contain 8 to 41 characters. Oracle Must contain 8 to 30 characters. PostgreSQL Must contain 8 to 128 characters. SQL Server Must contain 8 to 128 characters.
DB parameter group name	Must contain from 1 to 255 alphanumeric characters. First character must be a letter. Hyphens are allowed, but the name cannot end with a hyphen or contain two consecutive hyphens.
DB subnet group name	Must contain from 1 to 255 characters. Alphanumeric characters, spaces, hyphens, underscores, and periods are allowed.

File Size Limits in Amazon RDS

File size limits apply to Amazon RDS DB instances.

MySQL File Size Limits in Amazon RDS

For Amazon RDS MySQL DB instances, the maximum provisioned storage limit constrains the size of a table to a maximum size of 16 TB when using InnoDB file-per-table tablespaces. This limit also constrains the system tablespace to a maximum size of 16 TB. InnoDB file-per-table tablespaces (with tables each in their own tablespace) are set by default for Amazon RDS MySQL DB instances. For more information, see Amazon RDS DB Instance Storage.

Note

Some existing DB instances have a lower limit. For example, MySQL DB instances created prior to April 2014 have a file and table size limit of 2 TB. This 2-TB file size limit also applies to DB instances or Read Replicas created from DB snapshots taken before April 2014, regardless of when the DB instance was created.

There are advantages and disadvantages to using InnoDB file-per-table tablespaces, depending on your application. To determine the best approach for your application, go to InnoDB File-Per-Table Mode in the MySQL documentation.

We don't recommend allowing tables to grow to the maximum file size. In general, a better practice is to partition data into smaller tables, which can improve performance and recovery times.

One option that you can use for breaking a large table up into smaller tables is partitioning. Partitioning distributes portions of your large table into separate files based on rules that you specify. For example, if you store transactions by date, you can create partitioning rules that distribute older transactions into separate files using partitioning. Then periodically, you can archive the historical transaction data that doesn't need to be readily available to your application. For more information, see Partitioning in the MySQL documentation.

To determine the file size of a table

Use the following SQL command to determine if any of your tables are too large and are candidates for partitioning. To update table statistics, issue an ANALYZE TABLE command on each table. For more information, see ANALYZE TABLE in the MySQL documentation.

SELECT TABLE_SCHEMA, TABLE_NAME, 
    round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)", DATA_FREE 
    FROM information_schema.TABLES
    WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema'); 

To enable InnoDB file-per-table tablespaces

• To enable InnoDB file-per-table tablespaces, set the innodb_file_per_table parameter to 1 in the parameter group for the DB instance.

To disable InnoDB file-per-table tablespaces

• To disable InnoDB file-per-table tablespaces, set the innodb_file_per_table parameter to 0 in the parameter group for the DB instance.

For information on updating a parameter group, see Working with DB Parameter Groups.

When you have enabled or disabled InnoDB file-per-table tablespaces, you can issue an ALTER TABLE command. You can use this command to move a table from the global tablespace to its own tablespace, or from its own tablespace to the global tablespace as shown in the following example.

ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=COPY; 

MariaDB File Size Limits in Amazon RDS

For Amazon RDS MariaDB DB instances, the maximum provisioned storage limit constrains the size of a table to a maximum size of 16 TB when using InnoDB file-per-table tablespaces. This limit also constrains the system tablespace to a maximum size of 16 TB. InnoDB file-per-table tablespaces (with tables each in their own tablespace) is set by default for Amazon RDS MariaDB DB instances. For more information, see Amazon RDS DB Instance Storage.

There are advantages and disadvantages to using InnoDB file-per-table tablespaces, depending on your application. To determine the best approach for your application, go to InnoDB File-Per-Table Mode in the MySQL documentation.

We don't recommend allowing tables to grow to the maximum file size. In general, a better practice is to partition data into smaller tables, which can improve performance and recovery times.

One option that you can use for breaking a large table up into smaller tables is partitioning. Partitioning distributes portions of your large table into separate files based on rules that you specify. For example, if you store transactions by date, you can create partitioning rules that distribute older transactions into separate files using partitioning. Then periodically, you can archive the historical transaction data that doesn't need to be readily available to your application. For more information, go to https://dev.mysql.com/doc/refman/5.6/en/partitioning.html in the MySQL documentation.

To determine the file size of a table

Use the following SQL command to determine if any of your tables are too large and are candidates for partitioning. To update table statistics, issue an ANALYZE TABLE command on each table. For more information, see ANALYZE TABLE in the MySQL documentation.

SELECT TABLE_SCHEMA, TABLE_NAME, 
    round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)", DATA_FREE 
    FROM information_schema.TABLES
    WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema'); 

To enable InnoDB file-per-table tablespaces

• To enable InnoDB file-per-table tablespaces, set the innodb_file_per_table parameter to 1 in the parameter group for the DB instance.

To disable InnoDB file-per-table tablespaces

• To disable InnoDB file-per-table tablespaces, set the innodb_file_per_table parameter to 0 in the parameter group for the DB instance.

For information on updating a parameter group, see Working with DB Parameter Groups.

When you have enabled or disabled InnoDB file-per-table tablespaces, you can issue an ALTER TABLE command. You can use this command to move a table from the global tablespace to its own tablespace, or from its own tablespace to the global tablespace as shown in the following example.

ALTER TABLE table_name ENGINE=InnoDB, ALGORITHM=COPY;