As the hosting operator, increase allocated storage for an RDS-backed PD AWS MySQL service through the intended package or option change. This is separate from resizing its compute class and is not a storage-shrink operation.

Check the target allocation

Identify the current database, backing, allocated storage and free-space trend. Review the target value against the engine, plan and provider limits. RDS allocation here starts at the applicable provider minimum; do not use a smaller saved value as proof AWS will shrink an existing database.

Verify a usable recovery copy and arrange an appropriate application window. Review the billing effect before applying the change. A generated Storage option is not proof that every typed value is accepted by AWS.

Apply and verify growth

1. Review the package or Storage option that should apply to the service.
2. Process the supported change through Blesta.
3. Inspect the request and result under PD AWS MySQL → Activity.
4. Follow the database’s actual modification or optimisation state.
5. Confirm the resulting provider allocation and the saved service value agree.
6. Check the application and its free-storage graph afterwards.

The operation can be queued while the database is busy. A changed billing value does not by itself prove storage growth completed. Do not submit repeated increases simply to force the graph to update.

Understand limits

Allocated RDS storage cannot be reduced by lowering the option later. The module does not provide separate storage growth for a Lightsail bundle. Moving to a different backend, region or recovery resource is a separate migration task.

If a requested reduction or unsupported change is refused, review the actual provider allocation and the intended billing change. Compare the original Activity result with AWS before another request. Changing an order value does not establish that the database accepted it.

See the PD AWS MySQL Blesta guide for related tasks, or explore PD AWS MySQL.