ApsaraDB RDS:FAQ about storage capacity

Can I expand storage without migrating data? What are the impacts?

It depends on the host. If the host running your instance has enough free storage resources, the expansion happens in place—no data migration required. If the host can't provide enough capacity, RDS provisions a new host with sufficient storage and migrates your data there.

For details on how to expand storage and whether transient connections occur during the process, see the documentation for your database engine:

• Change the specifications of an ApsaraDB RDS for MySQL instance

• Change the specifications of an ApsaraDB RDS for PostgreSQL instance

• Change the specifications of an ApsaraDB RDS for SQL Server instance

• Change the specifications of an ApsaraDB RDS for MariaDB instance

How does billing change after a storage expansion?

Your instance fee changes to reflect the new storage capacity. For the exact billing calculation, see Billing details about configuration change.

How do I troubleshoot a sudden spike in storage usage?

1. Log on to the ApsaraDB RDS console and go to the Instances page. In the top navigation bar, select the region where your instance resides, then click the instance ID.

2. In the left navigation pane, click Monitoring and Alerts

How do I free up storage by deleting files?

See the solution guide for your situation:

• Storage exhausted by data files on a MySQL instance

• Storage exhausted by binary log files on a MySQL instance

• Storage exhausted by temporary files on a MySQL instance

• Storage exhausted by system files on a MySQL instance

Why does an empty database still use storage?

When a database initializes, it creates system tables to store account and permission metadata. The database engine also writes redo logs and undo logs as part of normal operation. This baseline storage usage is expected and unavoidable.

Why does MySQL use more storage than the source database after a heterogeneous migration?

Different database engines handle data differently. MySQL's storage usage is shaped by its compression behavior and the indexes it builds on certain fields—both of which can result in a larger footprint than the source database.

Does the storage capacity parameter include backup storage?

No. The Storage Capacity value shown in the Usage Statistics section of the Basic Information page reflects only instance storage—backup storage is counted separately. To see your backup storage usage, see View and manage the size of backup files.

After storage is exhausted, how long before the instance enters the Locking state? What do I do?

When storage is exhausted, the instance is automatically locked and enters the Locking state. Because of the inspection mechanism's polling interval, locking may happen at a slight delay—there is no guaranteed immediate lock.

Once locked, the instance rejects all write operations. To prevent this, configure alerts so you're notified before storage fills up—see Configure alerting. You can also enable automatic storage expansion so RDS expands storage automatically when usage crosses a threshold:

• Configure automatic storage expansion for a MySQL instance

• Configure automatic storage expansion for a PostgreSQL instance

• Configure automatic storage expansion for a SQL Server instance

For MySQL instances, you can also enable automatic fragment reclamation to recover fragmented space without manual intervention.

If your instance is already locked, see What do I do if my ApsaraDB RDS instance is in the Locking state? for recovery steps.

After deleting a large amount of data on SQL Server, why hasn't the disk space decreased?

This is expected behavior in SQL Server. Deleting data doesn't immediately return disk space because of how the engine handles storage internally:

• Transaction logs: Every DELETE operation is recorded in the transaction log to support rollback and recovery. Even after data is deleted, those log records continue to occupy disk space—and during heavy deletions, log growth can temporarily increase total disk usage.

• Reusable data pages: SQL Server marks deleted data pages as reusable rather than freeing them immediately. This avoids costly physical disk recycling and makes subsequent inserts faster. The pages remain allocated until reclaimed.

• Index and table fragmentation: Deleting rows leaves gaps in tables and indexes. SQL Server treats this fragmented space as allocated, so it doesn't appear as free disk space.

To reclaim disk space, use one or more of these approaches:

• Shrink the database or files: Run DBCC SHRINKDATABASE or DBCC SHRINKFILE to return unused space to the operating system.

  Important

  Shrinking is time-consuming and can hurt performance if run frequently. For guidance, see Solve SQL Server locking when storage is full or Troubleshoot insufficient storage on a SQL Server instance.

• Rebuild indexes: Rebuilding fragmented indexes reorganizes data pages and reclaims the space left by deleted rows, which also improves query performance.

• Back up transaction logs: For databases using the full recovery model, regularly backing up transaction logs allows SQL Server to truncate them and free up log space. See Manage logs.

• Use TRUNCATE TABLE instead of DELETE: When removing all rows from a table, TRUNCATE TABLE releases data pages immediately and generates far fewer log records than DELETE.

  Important

  TRUNCATE TABLE is irreversible and doesn't support a WHERE clause. Use it only when you intend to remove all rows.

After expanding storage, does the free backup storage quota increase?

Yes. The free backup storage quota scales with the instance's storage capacity:

The quota is calculated in GB and rounded up to the nearest integer.