RDS Storage-Full: Fix It Now and Stop It Happening Again

If your Amazon RDS instance says storage-full, the fastest fix is almost always increasing allocated storage by at least 10% through the console or CLI — but here's the part almost nobody tells you until it's 2 a.m.: turning on storage autoscaling does not stop this from happening again. The famous six-hour lockout that most guides still warn about was retired in July 2026, yet autoscaling still has to wait for "storage-optimization" to finish after every change, and it gets at most four changes in any 24 hours. Your dashboard can say autoscaling is on and green while the database keeps rejecting every write.

Jake found out about this the hard way on a Tuesday. His shop runs a small order-tracking database on RDS — nothing fancy, just customer repairs and parts orders. One busy back-to-school week, the app started throwing errors on every save. Orders stopped saving. A customer stood at the counter while Jake stared at a console that said his database was "storage-full," with autoscaling turned on the whole time.

"I thought I set this up so it would just grow when it needed to," Jake said. "Isn't that the whole point?" Ethan didn't sugarcoat it: "It is the point — but it has rules, and one of them is going to feel personal the first time it stops you."

What "storage-full" actually means on RDS

An Amazon RDS database instance doesn't run directly on a hard drive in a data center you'd recognize. It runs on top of Amazon EBS (Elastic Block Store) — think of it as a virtual hard drive that AWS attaches to your database's compute instance. You tell RDS how big that virtual drive should be when you create the instance: that number is your allocated storage. Once your data, indexes, logs, and temporary files fill that drive up, RDS puts the instance into the storage-full state.

This isn't a vague "getting low" warning. It's a hard stop, and it's more disruptive than most people expect: a DB instance in storage-full doesn't just refuse new writes — it doesn't have enough available space to perform basic operations at all. You typically can't connect to it, and you can't even restart it. The instance will only accept one kind of change while it's in this state: a modification to allocated storage. Every other request — a parameter change, a reboot, a snapshot restore trigger — gets rejected outright.

The exact free-space number that triggers storage-full depends on how big your allocated storage already is. For RDS for MySQL, for example, the cutoffs work like this:

That's the officially documented cutoff for the MySQL engine family. Other engines use similarly tiered thresholds, but the exact numbers shift with how much storage you provisioned — which is exactly why a database that's been fine for two years can suddenly cross the line without you changing anything. As the data grows, the safety margin around it doesn't grow at the same pace.

One more MySQL-specific detail from the same AWS page: to protect against metadata inconsistencies and orphaned tables, RDS automatically stops a MySQL instance that reaches storage-full. A stopped instance can still be modified, and making a storage change (or turning on autoscaling) is how you bring it back.

When the instance actually reaches this state, RDS for MySQL and MariaDB does something a lot of people don't expect: it automatically stops the instance. It's not being punitive — a database that keeps trying to write to a full disk risks corrupting data files, so RDS pulls the plug rather than let that happen. To bring it back, you have to either enable storage autoscaling or manually increase the storage; either change triggers an automatic restart once it takes effect.

Why storage autoscaling doesn't always save you

This is the part of the story that catches people who did everything "right." Jake had turned on autoscaling months earlier, set a generous maximum, and never thought about it again. That's usually the correct move — but autoscaling has rules that only bite you the one day it matters most.

Rule 1: It only fires when free space is already low, and only after a delay

RDS starts a storage increase automatically only when all of the following are true at once: free space has dropped to 10% or less of your allocated storage, that low-storage condition has lasted at least five minutes, and storage-optimization from the previous storage change has finished, with fewer than four storage changes made in the past 24 hours. Five minutes doesn't sound like much, but a large batch import, a runaway log file, or an unindexed query writing temp files can eat 10% of a multi-hundred-gigabyte volume faster than that window allows RDS to react.

Rule 2: Storage changes still queue behind storage-optimization — the six-hour rule is gone, the wait is not

Here's what trips up almost everyone, including teams who've run RDS for years. Until July 2026, RDS enforced a six-hour cool-off after any storage modification, automatic or manual. AWS retired that rule in July 2026: RDS now allows up to four storage modifications in any rolling 24 hours, and a new one can start as soon as the previous change finishes a state called storage-optimization. That's a real improvement, but plenty of blog posts and forum answers still quote the old six-hour number. Storage-optimization is the background process where the new volume settles in; it usually takes a few minutes, but AWS's own documentation is explicit that it can take more than 24 hours if the new volume hasn't fully initialized. While that's happening, autoscaling cannot increase your storage again, no matter how low free space drops.

So the sequence that catches people is: autoscaling adds space once, the database keeps growing (because whatever caused the spike is still happening), free space hits zero again, and the instance goes storage-full — while autoscaling sits there, correctly configured, unable to do anything until storage-optimization finishes, or until the 24-hour window frees up another change.

Rule 3: The increment might be smaller than what you actually need

When autoscaling does fire, it doesn't jump to your maximum threshold. It adds whichever is greatest of: 10 GiB, 10% of your currently allocated storage, or a predicted 7-hour growth estimate based on the last hour's free-space trend. For a small, slow-growing database that's plenty. For a database mid-way through a bulk data load — say, migrating 50 GB of records in under an hour — a 10% bump bought while the last bump is still in storage-optimization simply isn't enough runway. This is documented directly: autoscaling can't completely prevent storage-full situations during large, fast data loads, and a database can sit in storage-full for several hours as a result.

Fixing an active storage-full state right now

If your instance is storage-full right now, work through this in order. Each step is cheaper and faster than the next, and you should attempt an earlier step before jumping to a more drastic one.

1. Stop anything still writing to the database. If a batch job, an import script, or replication is actively pushing data in, pause it. Writes into a full volume just re-trigger the same wall the moment you make room.
2. Confirm the instance status is actually storage-full in the RDS console or with aws rds describe-db-instances, rather than assuming from the symptom — a database that's merely slow or unreachable for another reason needs a different fix entirely.
3. Check whether a storage modification is already in progress. Look at recent events for messages like "Finished applying modification to allocated storage" or "Finished applying autoscaling-initiated modification to allocated storage." If one is still in storage-optimization, you can't stack another change on top until it finishes — skip to the next section.
4. If no modification is pending, increase allocated storage manually, by at least 10%. In the console: select the instance → Modify → raise the Allocated storage value → Apply immediately. A smaller increase than 10% is rejected outright.
5. Or do it from the command line with something like aws rds modify-db-instance --db-instance-identifier your-db-id --allocated-storage 200 --apply-immediately, substituting your instance ID and target size.
6. Wait for the instance to reach the "modifying" state, then reconnect. A DB instance in "modifying" is operational again even before storage-optimization fully finishes, and in most cases a modest increase is enough to get you back in so you can do further diagnosis.
7. Once you're back in, immediately turn on storage autoscaling with a realistic maximum threshold, so you're not manually fighting this same fire again in a month. The section below covers the settings that actually matter.

Already stuck waiting on storage-optimization? Your three real options

This is the situation nobody enjoys explaining to a boss or a customer: the console won't let you modify storage, and it isn't because you're doing anything wrong. You're waiting for an ongoing storage-optimization process to finish, which can, in unlucky cases, run past 24 hours, or you've already used the four storage changes allowed in a rolling 24-hour window. Here's what's genuinely available to you during that window.

Notice what's missing from that list: there is no console button that skips storage-optimization. If a vendor blog post or forum comment tells you there's a trick to force it through, that advice is wrong — waiting for storage-optimization is a hard platform rule, not a setting you can override.

How to find out what's actually eating your storage

The FreeStorageSpace metric in CloudWatch tells you how much room is left, but it never tells you why the room disappeared. On RDS for MySQL and MariaDB, storage is shared across a specific set of things: user-created databases, temporary tables, binary logs (or relay logs on a read replica), the InnoDB tablespace itself, and the general, slow-query, and error logs. Any one of these can quietly become the real culprit.

If free space drops suddenly, look at what's running

A sharp, sudden drop — rather than the slow, steady decline of normal growth — usually means something is actively happening right now. Run SHOW FULL PROCESSLIST to see every active connection and query on the instance. If you suspect a long-running transaction is the cause (these can bloat temporary space and hold onto data that would otherwise be cleaned up), check INFORMATION_SCHEMA.INNODB_TRX or run SHOW ENGINE INNODB STATUS and review the output for anything that's been open far longer than it should be.

Find out which database, and which table, is actually the size you think it is

To see how much space each database is using, a query against INFORMATION_SCHEMA.FILES grouped by database name will break it down by reusable (free) space versus total allocated space per database, letting you sort by the biggest first. At the table level, querying information_schema.tables for data_length, index_length, and data_free shows you not just how big a table is, but how much of that size is dead weight — space that's allocated to the table but not actively storing anything.

Reclaiming fragmented space with OPTIMIZE TABLE

That data_free column is often reclaimable. If innodb_file_per_table is on (it's the RDS default), running OPTIMIZE TABLE against a bloated table can hand that space back. On RDS, this command doesn't run literally — it's translated internally into an ALTER TABLE...FORCE, which rebuilds the table. You may see a message like "Table does not support optimize, doing recreate + analyze instead" when this happens; that's expected, not an error to panic over. It works for InnoDB, MyISAM, and ARCHIVE tables, and it needs headroom to run, so it's a maintenance-window task, not a mid-emergency one.

Setting up autoscaling so this doesn't repeat

Autoscaling has real limits, but it's still the single biggest lever you have, and it's simple to configure correctly once you know what the settings actually control.

1. Set a maximum storage threshold with real headroom. AWS requires it to be at least 10% above your current allocated storage, but recommends going higher — at least 26% more — specifically to avoid getting repeated "approaching maximum storage threshold" notifications every time normal growth nudges the ceiling.
2. Via the console: Modify the instance → check "Enable storage autoscaling" → set "Maximum storage threshold" → Apply.
3. Via the CLI: aws rds modify-db-instance --db-instance-identifier your-db-id --max-allocated-storage 1000 --apply-immediately turns on autoscaling with a 1,000 GiB ceiling.
4. If you manage infrastructure as code, the equivalent Terraform setting is max_allocated_storage on the aws_db_instance resource, sitting alongside your base allocated_storage value — keep both under version control so a review catches an accidental ceiling that's too low, or too close to the current size, before it ships.
5. Set a CloudWatch alarm on the FreeStorageSpace metric at a threshold well above the autoscaling trigger point — 20–25% free, not 10% — so a human gets paged before RDS is forced into emergency mode.

Why the database keeps filling back up even after you add storage

Ethan's line on this one is blunt: "Adding storage without finding what's eating it is like buying a bigger trash can because your kitchen smells. It buys you time. It doesn't fix anything." Jake didn't love hearing that, but it's the honest read.

Storage isn't only your rows and tables. Several things quietly consume the same allocated space, and which one is the real driver depends heavily on your engine:

PostgreSQL: dead tuples and bloat

PostgreSQL doesn't immediately reclaim space when a row is updated or deleted — it marks the old version as a "dead tuple" and relies on a background process called autovacuum (the term for how PostgreSQL cleans up leftover row versions) to reclaim it later. If autovacuum falls behind — which AWS's own documentation flags as a real risk on databases with very high object or table counts — dead tuples pile up and your allocated storage fills with data that no longer represents anything useful. Starting with RDS for PostgreSQL version 18, RDS can dynamically scale up the number of autovacuum workers as a database approaches transaction ID wraparound, without requiring a restart — a meaningful improvement, but not a substitute for watching your bloat.

MySQL and MariaDB: binary logs and replication

Binary logs record every change for replication and point-in-time recovery. If binary log retention is set too generously, or a replica falls behind and RDS can't purge logs the replica still needs, those logs accumulate on the primary's own storage — one of the documented storage consumers alongside temporary tables and the InnoDB tablespace itself.

Any engine: temporary files and unlogged or temp tables

Large sort operations, index builds, and temporary tables all write to disk under load. AWS's guidance on high object counts in PostgreSQL specifically calls out temporary files and temporary tables as contributors to general performance and storage impact when left unmanaged. This is the one that catches people off guard because it isn't tied to your permanent data size at all — it's tied to what your queries are doing right now.

Jake learned this one directly. Every Sunday evening, right after the youth soccer league wraps up at the field down the road, his shop gets a wave of parents wanting photos pulled off cracked phones before the school week starts. The app generates thumbnail previews for the batch, and those preview jobs build large temporary result sets while they run. For an hour or two every Sunday night, his FreeStorageSpace graph dips in a pattern that looks alarming until you know what it is — a temp-table spike tied to a predictable weekly rush, not a leak. "I used to think my database was dying every Sunday," Jake said. "Turns out it was just busy."

Oracle: autoextending tablespaces

Oracle tablespaces configured to autoextend will keep growing to accommodate data without anyone deciding that's supposed to happen, quietly eating allocated storage in the background until a checkup surfaces it.

The takeaway isn't "add more storage forever." It's: after you resolve an active storage-full incident, go back and find out which of these was the actual driver, using the queries and tools from the section above, because the next storage-full alert is coming from the same source if you don't.

Large data loads: the one scenario autoscaling genuinely can't cover

Picture a migration: you're loading 50 GB of historical order data into Jake's database in under an hour, because that's the maintenance window the team agreed on. Autoscaling adds 10% of current storage the first time free space drops below the 10% line. If the load keeps going and that new headroom evaporates before storage-optimization finishes — which, at 50 GB in under an hour, it very well might — you're back in storage-full, and autoscaling has nothing left to offer until optimization finishes.

This is documented directly by AWS: storage autoscaling can't completely prevent storage-full situations for large data loads, precisely because each change must wait for storage-optimization and only four changes fit in 24 hours. The fix isn't a setting — it's planning. Before any load you know is coming, manually size the instance up to comfortably exceed what the load will add, rather than trusting autoscaling to react in real time. If the load is recurring — a monthly import, a quarterly archive job — build the pre-sizing step into the runbook for that job permanently, rather than remembering it fresh each time.

The hard ceiling: storage limits by engine and storage type

"It will not just grow" has a second, more literal meaning: there's a real ceiling, and once your database approaches it, autoscaling and even manual increases eventually run out of runway entirely.

Two things worth explaining here in plain terms. First, "GiB" (gibibyte) is the exact binary unit AWS meters storage in — it's almost the same as a gigabyte (GB), just measured in binary steps of 1,024 instead of round 1,000s, so the two numbers are close enough that you can treat them interchangeably in everyday planning. Second, notice that SQL Server's ceiling is a quarter of what MySQL or PostgreSQL get on the same storage type — a detail that matters if you're choosing an engine for a database you expect to grow into multiple terabytes.

One more wrinkle worth knowing if you're on gp3 storage: the amount of storage you provision also sets your default I/O performance (IOPS — the number of read/write operations per second the volume can handle, similar to how many customers a shop counter can serve per minute). On gp3, the default is 3,000 IOPS for smaller volumes, stepping up to 12,000 IOPS once you cross a size threshold that varies by engine (roughly 400 GiB for MariaDB/MySQL/PostgreSQL, 200 GiB for Oracle, and SQL Server which defaults to 3,000 IOPS regardless of size). So a storage increase isn't purely a capacity decision — on some engines, it quietly changes performance too.

The other half of "it will not just grow": it also won't shrink

This surprises people in the opposite direction. Say you panic-increase storage to 2 TB to escape a storage-full incident, then later clean up the data that caused the spike and only actually need 200 GB. On classic RDS provisioned storage, there's no dial to turn back down. Once storage has been increased — whether by autoscaling or manually — that allocated storage can't be reduced. You keep paying for 2 TB indefinitely.

The only way to actually shrink allocated storage on classic RDS is to move the data to a new, smaller instance: either a logical export and import (a database dump and restore) or an AWS Database Migration Service job into a freshly sized instance. There is no in-place "Modify → decrease storage" option, because RDS provisioned storage was never designed to release space back once it's been claimed.

Aurora, again, is the exception. Because Aurora tracks actual data volume and shrinks the cluster volume — and the bill — when you drop tables or databases, it doesn't carry the same one-way-ratchet problem for workloads with big seasonal cleanups.

Monitoring so you see this coming

The single most useful metric here is FreeStorageSpace in Amazon CloudWatch (AWS's built-in monitoring service — think of it as the dashboard of gauges sitting behind every AWS service, watching numbers so you don't have to). A steady, gradual decline is normal growth. A sudden, sharp drop is the signal that something unusual — a runaway job, an unindexed query building huge temp files, a replica falling behind and blocking log cleanup — is happening right now, before it becomes an outage.

Set at minimum two alarms: one early warning around 20–25% free space that pages a human during business hours, and a second, more urgent one around 10–12% free that treats the situation as active. Pair that with a "storage size approaching maximum storage threshold" event subscription, which fires specifically when your allocated storage is closing in on the autoscaling ceiling you configured — a sign it's time to raise that ceiling before autoscaling paints itself into a corner.

Once you've watched your own graph for a month or two, you'll start recognizing your database's normal rhythm, the way Jake now recognizes his. A dip that lines up with a known weekly or monthly pattern isn't cause for panic; a dip with no obvious cause is exactly what the early-warning alarm is for.

Do you need a third-party monitoring tool for this?

Plenty of paid database-monitoring platforms will happily sell you a dashboard for exactly this problem. Here's the honest read: for a single instance or a handful of them, CloudWatch's FreeStorageSpace metric plus alarms and an event subscription covers the core need — you'll know it's happening, and you'll know before it's an outage. That costs nothing beyond what you're already paying for RDS.

Where a third-party tool starts earning its keep is at scale: dozens of instances across multiple accounts, where a single pane of glass and automated anomaly detection saves real time versus checking each instance's alarms individually, or where you want historical trend analysis and capacity forecasting beyond what CloudWatch's default retention gives you. If you're managing one or two databases for a small operation like Jake's shop, that's spending money to solve a problem CloudWatch and a Slack webhook already solve for free. Match the tool to the scale of the problem, not the other way around.

When to stop fighting storage and consider Aurora

Jake's shop database will probably never need this conversation — a few gigabytes of repair orders isn't going to bump into a 64 TiB ceiling. But if you're managing a database that's approaching the storage ceiling for its engine, that regularly does large seasonal purges and wants that space back, or that's been burned more than once by storage-optimization waits mid-migration, Aurora's storage model addresses all three directly: a much higher ceiling (up to 256 TiB on supported versions), automatic growth without the same fixed increment-and-wait pattern, and a volume that actually shrinks — and stops billing you — when you remove data.

That's not a universal recommendation. Aurora is a different engine architecture with its own migration path, its own pricing model, and its own learning curve. But if this article is the third time this year you've fought a storage-full incident on the same instance, it's worth treating the migration conversation as a real option rather than a last resort.

Frequently asked questions

What does "storage-full" mean on an RDS instance?

It means free space on the instance's allocated storage has dropped to a threshold RDS considers unsafe, and the instance no longer has enough available space to perform basic operations — you typically can't connect to it or restart it, and it will accept only allocated-storage modifications. For some engines, including MySQL and MariaDB, RDS also automatically stops the instance to prevent data-file corruption from writes hitting a full disk.

Why isn't my RDS storage autoscaling even though I turned it on?

The most common reason is that the previous storage change — automatic or manual — is still in storage-optimization, or that four storage changes have already happened in the past 24 hours. Until one of those clears, autoscaling cannot fire again no matter how low free space drops.

How long does it take for RDS to come out of storage-full?

Once a storage modification is accepted, the instance typically becomes reachable again once it enters the "modifying" state, even before the storage-optimization process fully completes. Storage-optimization itself usually takes minutes, but AWS documentation notes it can take more than 24 hours in some cases, particularly when the new volume hasn't fully initialized.

Can I speed up recovery from storage-full?

Not by forcing the process. What helps most is stopping active writes immediately, confirming there isn't a pending modification already queued, and increasing storage by at least the required 10% right away rather than a smaller amount that gets rejected and costs you another round trip.

Why can't I modify storage again right after I just increased it?

This is a platform-level protection, not a bug. RDS waits until the last change finishes storage-optimization before it accepts another, to protect the volume while it settles. Since July 2026 there is no longer a separate six-hour cool-off, but you can make at most four storage modifications in any rolling 24 hours.

Does RDS ever shrink allocated storage automatically?

No, not on classic RDS provisioned storage — allocated storage only ever increases. Amazon Aurora is the exception: on supported versions, its cluster volume actually shrinks, and your bill drops, when you remove data.

Can I decrease allocated storage after autoscaling has increased it?

No. Once storage has been increased on a classic RDS instance, that allocated storage can't be reduced in place. The only path to a smaller footprint is migrating the data to a new, smaller instance via export/import or AWS Database Migration Service.

What's the maximum storage size for an RDS instance?

It depends on engine and storage type: up to about 64 TiB for MySQL, MariaDB, PostgreSQL, and Oracle on General Purpose or Provisioned IOPS storage; up to about 16 TiB for SQL Server on the same storage types; much lower for legacy magnetic storage. Aurora's cluster volume can grow up to 256 TiB on supported engine versions.

Will a big data import trigger storage-full even with autoscaling on?

Yes, it can. If the import consumes storage faster than autoscaling's increment can keep pace with, or happens while a previous storage change is still in storage-optimization, the instance can land in storage-full for hours. The documented fix is to manually pre-size storage before a known large load, rather than relying on autoscaling to react in time.

What happens to my database connections during storage-full?

Writes fail, and on engines like MySQL and MariaDB the instance is typically stopped automatically by RDS, which also drops existing connections until it restarts after the storage fix is applied.

Does stopping and restarting the instance fix storage-full?

No. Restarting doesn't create free disk space, and in a storage-full state the instance typically can't even be restarted in the first place. The instance needs an actual storage increase; the automatic restart you see happens as a consequence of that storage change being applied, not as a fix on its own.

Is Multi-AZ affected differently by storage-full?

Storage-full is a property of the underlying storage volume, so a Multi-AZ deployment can hit the same threshold and storage-modification rules on its primary. Multi-AZ protects against instance or AZ failure; it doesn't create extra headroom against running out of disk space.

Why does my database keep filling up again days after I add storage?

Adding storage buys time; it doesn't remove the cause. Common repeat offenders are PostgreSQL bloat from autovacuum falling behind, accumulated binary logs on MySQL/MariaDB, stale replication slots holding onto log data, or autoextending tablespaces on Oracle. Querying information_schema for per-database and per-table size, and checking for long-running transactions, usually surfaces the real driver.

Should I just set the max storage threshold really high and forget it?

Set it generously — at least 26% above your current allocated storage, per AWS's own recommendation — but "forget it" is the mistake. A high ceiling without monitoring just means you find out about a runaway growth problem later and at a bigger, more expensive size.

Is Aurora a permanent fix for this problem?

It removes two specific pain points — the low fixed ceiling and the inability to shrink storage back down — and offers a much higher maximum. It doesn't remove the need for monitoring or make every possible storage scenario disappear, but for workloads that regularly bump into RDS provisioned storage's limits, it's a legitimate structural fix rather than a workaround.

Is the six-hour wait between RDS storage modifications still a rule?

No. Since July 2026, Amazon RDS allows up to four storage modifications in any rolling 24-hour window, and a new one can start as soon as storage-optimization for the previous change completes. The old six-hour cool-off no longer applies to RDS for MySQL, MariaDB, PostgreSQL, Oracle, SQL Server or Db2, but storage-optimization itself can still take hours.

Revision note. Written September 2026, covering RDS for MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server on classic provisioned storage, with Aurora's storage model covered for comparison. Updated for AWS's July 2026 change that replaced the six-hour cool-off with up to four storage modifications per rolling 24 hours. This will need a fresh look if AWS changes that limit or the autoscaling increment formula. If you landed here mid-outage: take a breath, work through the steps in order, and know that this exact situation has a fully documented, non-destructive way out.

s