RDS Low Storage with Autoscaling Enabled: Decide What Can Grow Now

Join RDS free-space units, current allocation, maximum storage, optimization state and modification history before relying on another automatic increase.

Primary sources checked 2026-10-18

Storage autoscaling being configured does not establish that an RDS instance can add space before the next load fills it. Compare current free space with allocated storage, then check the maximum threshold, storage optimization and modification history. If a required observation is missing, assign that gap instead of predicting the next successful increase from a checkbox.

This guide helps a database owner and incident lead assess low free storage on an existing RDS for PostgreSQL DB instance with a supported SSD storage configuration. It covers the primary allocated storage volume, not Aurora, RDS Custom, Multi-AZ DB clusters, additional volumes, local NVMe scratch space or storage migration execution. It produces a capacity-risk record and an owned investigation or change proposal. No database, AWS account or customer workload was exercised; all worked values are synthetic.

Establish the resource and storage that are under pressure

Capture account, Region, DB instance identity, engine/version, deployment type and observation time. Preserve DbiResourceId alongside the current identifier/ARN so a renamed or replaced instance does not silently inherit another instance's history. Retain allocated storage, storage type, maximum allocated storage, status and pending modification fields from the same dated control-plane read. DBInstance response fields.

Start with approved existing exports. A denied read, stale screenshot or response for a similarly named replica leaves the affected resource unresolved. Inspect any replica or cluster relationship before applying an instance-only conclusion. A storage warning on a dedicated log volume or local instance storage needs its own applicable metric and operation contract.

Record which workload is still adding data. A scheduled import, retained transaction logs, temporary work and ordinary application writes can produce different growth patterns. This procedure does not authorize SQL reads of customer tables, administrative cleanup or disabling an application. Ask the database and application owners for sanitized workload evidence and the available incident controls.

Preserve the current configuration before proposing anything. A screenshot from last week can explain what the team intended, but not the current maximum or whether a previous modification is still optimizing. Separate observed state from a remembered setting and from a pending requested setting.

Put free space and allocation in compatible units

CloudWatch reports FreeStorageSpace in bytes, while the instance's allocated-storage field is expressed in GiB. The console can display other units. Convert before calculating a percentage and retain the raw values, metric dimensions, statistic, period and time window. RDS metric units.

For a constructed 1000 GiB allocation, the equivalent is 1000 times 1,073,741,824 bytes. A free-space observation of 42,949,672,960 bytes is 40 GiB, or 4 percent. Comparing the raw byte number directly with 1000 would reverse the meaning of the observation. Using decimal gigabytes for only one side introduces a smaller but still avoidable error.

Free space is not a work-completion counter. It does not show whether one import committed, which rows are expendable or whether an application is healthy. A storage increase can improve available bytes while leaving an interrupted business operation unresolved. Keep incident recovery checks separate from capacity measurements.

Sparse observations also have limits. Six points below a threshold can bound a sampled trend, but missing periods and aggregation can conceal a different history. Record the collection coverage before claiming a low-storage condition persisted. A synthetic example can stipulate continuity; a production worksheet needs supporting observations.

Check the documented trigger and the live blockers separately

The current RDS autoscaling guide describes free space at or below 10 percent for at least five minutes, completion of the previous storage optimization and fewer than four storage modifications in the preceding 24 hours. It also documents the configured maximum and supported-storage constraints. These are service conditions, not a promise that space appears at a particular minute. RDS storage autoscaling.

Check each item against the affected instance rather than treating one true setting as the whole decision. Is the required pressure interval supported? Is the current maximum distinct from the allocation and sufficient for the proposed increment? Is an earlier storage operation still optimizing? Is the modification history complete enough to assess the applicable limit?

The reviewed AWS sources use different timing descriptions. The current user guide states the four-modifications-per 24-hours condition; an AWS support article still describes six hours since the prior modification or optimization completion, whichever is later. AWS low-free-storage support guidance. Do not reduce those descriptions to an unconditional six-hour countdown. If the exact next eligible time controls an incident decision, ask AWS Support to resolve the applicable behavior for the instance while preserving both dated references and actual state.

This limit does not prevent useful diagnosis. An optimization still in progress is a concrete blocker under both descriptions. A missing current allocation, unknown maximum or incomplete event history is a concrete evidence gap. The decision can identify either without pretending to implement the entire RDS scheduler.

Treat the maximum as a boundary, not a reservation

RDS chooses the increase using documented minimum and prediction-related inputs; the autoscaling guide includes 10 GiB,10 percent of current allocation and a growth prediction based on recent free-space history. A worksheet that calculates only 10 percent has not reproduced that prediction. Do not advertise its result as the next requested or actual allocation.

For 1000 GiB,10 percent is 100 GiB, which is greater than 10 GiB. That arithmetic supplies one lower-bound component, not a complete forecast. If the owner has permitted a maximum 1500 GiB,500 GiB of allocation headroom exists numerically. That does not establish the next increment, its eligibility or its completion time. An applicable increment exceeding the maximum can prevent autoscaling.

Setting maximum allocated storage equal to allocated storage prevents further autoscaling through that setting. A historical label saying “autoscaling enabled” cannot override the current field values. The autoscaling configuration guide also explains that changes to the autoscaling limit take effect immediately, regardless of the Apply immediately selection. Raising it is a real cost-exposure decision, not a harmless metadata correction.

Allocated storage cannot be reduced in place by reversing the increase. A later migration or supported replacement design is a separate recovery/cost decision. Increasing instance storage. Preserve this asymmetry when approving headroom: the ability to restore an application setting does not restore the previous storage allocation or erase associated spending.

Use growth arithmetic to express urgency, not predict service completion

Assume an invented instance has 40 GiB free at 10:05 UTC. Over a separately stipulated stable five-minute interval, free space fell from 80 to 40 GiB with no space-releasing event. Net consumption is 40 divided by 5, or 8 GiB per minute. Continuing that rate would consume the remaining 40 GiB in another five minutes.

That is a conditional time-to-exhaustion calculation. It is not an RDS growth prediction, an observed outage time or a guarantee that a paused import would immediately release 40 GiB. The future rate may change, transactions may retain space, and a storage modification may not finish within the interval. Record the assumption beside the result rather than placing “five minutes to recovery” on an incident banner.

Compare this conditional horizon with known blockers and owned response time. If optimization is still running and no completion estimate is supported, waiting for autoscaling is an unbounded recovery dependency. The incident lead should review the application's already-approved admission or workload controls with its owner, while the database owner investigates capacity options. Do not invent authority to kill sessions or delete data.

A growth trend can also be stale or misleading. A one-off load can flatten after completion; a new batch can accelerate it. Retain a more recent comparison when available and show both intervals if they disagree. Separate a projection the owner accepts for planning from a measured service capability.

Worked scenarios: optimization, capacity cap and missing history

These records use fabricated configuration and metric values. They classify a next action, not AWS responses or tested repairs.

A, optimizing

Stipulated evidence: 1000 GiB allocated;1500 GiB maximum;40 GiB free; prior storage optimization active

Decision: Do not rely on an immediate increase; database owner resolves optimization/state and incident lead reviews owned load controls

B, current cap

Stipulated evidence: 1000 GiB allocated; maximum also 1000 GiB; old screenshot says enabled

Decision: Current setting prevents further autoscaling; prepare a separately approved limit/cost decision

C, missing history

Stipulated evidence: 1000 GiB allocated;1500 GiB maximum; low-space samples present; optimization and modification history unknown

Decision: Eligibility unresolved; collect exact state/history rather than schedule a six-hour retry

For A, even a maximum with ample numerical headroom does not remove the optimization blocker. If a later observation shows optimization complete, add a new row and assess the remaining conditions. Do not edit A to imply its original waiting decision was supported by evidence obtained afterward.

For B, the owner could propose a higher maximum, a planned capacity increase or a workload change. Each needs its own supported limits and cost review. The diagnosis has established a configuration boundary, not selected the cheapest or safest repair. A second request to modify storage can also interact with an automatic operation; preserve any already-pending work before proposing another change.

For C, no favorable interpretation can fill the missing history. RDS documents that autoscaling operations are not logged in CloudTrail, so the absence of a matching API event is not proof that none occurred. Use applicable instance events and storage/state observations; document what their retained coverage cannot reconstruct. Escalate the unresolved eligibility question instead of fabricating four known daily modifications or a known last-modification time.

Compare interventions against the constraint they change

Continuing observation may be suitable when the growth horizon and current service state support the owner's waiting decision. It is unsuitable when the proposed response relies on an unknown completion time and consumption is already urgent. A dashboard alarm alone does not supply either missing fact.

Increasing a maximum changes the ceiling, not every readiness condition. A manual allocation request is a different operation from editing the autoscaling ceiling. Review supported storage modifications for the actual instance and present state. DescribeValidDBInstanceModifications supplies applicable modification options; a successful read is not acceptance or completion of a modification.

Reducing admitted work can change the growth rate without adding storage, but the application owner must understand queueing, retries and partially completed jobs. Deleting or compacting data can be destructive or require working space. Do not recommend either as an emergency generic SQL recipe. Treat retention, replica/log dependencies and business recovery as owner decisions.

A replacement or restore path can provide another capacity design, but introduces data currency, credentials, endpoint and writer-authority questions. The RDS snapshot restore rehearsal owns a specific lifecycle exercise, not an emergency zero-loss replacement. The database scaling playbook owns broader bottleneck choices. Reuse their controls rather than presenting a new instance as an instant escape from an existing incident.

Retain a capacity-risk worksheet with explicit unknowns

Resource and scope

Evidence to record: Account/Region, DbiResourceId, identifier/ARN, PostgreSQL version, deployment/storage type and capture time

Pressure calculation

Evidence to record: Raw free bytes, allocated GiB, exact conversion, statistic/period, complete observation interval and unknown samples

Growth and urgency

Evidence to record: Chosen comparison interval, net change, assumed future rate and conditional exhaustion horizon

Current readiness

Evidence to record: Maximum, optimization/status, pending modifications, retained modification/event history and unresolved timing contract

Proposed action

Evidence to record: Which constraint changes, supported operation, separate authority, cost exposure and effect on admitted work

Acceptance and recovery

Evidence to record: Required capacity/state readback, application reconciliation, remaining risk, next owner and observation deadline

Use the worksheet to ask a falsifiable question. “Can the owner-approved action add sufficient capacity under the current state before the accepted workload exhausts it?” requires more than “is autoscaling on?” If the forecast component, resource limit or observation coverage is missing, describe that gap instead of asserting readiness.

An isolated follow-up should use a disposable PostgreSQL instance, synthetic data, bounded cost approval and inert application dependencies. Agree stop conditions before any loading or modification. An unexpected live endpoint, unresolved identity, approaching spend boundary or missing telemetry stops the exercise. No fixture in this guide authorizes such execution.

Next action: assign the first blocker and preserve the recovery boundary

Start with one dated instance read and one correctly dimensioned free-space interval. Have the database owner complete the optimization and maximum fields, then ask the incident lead whether waiting is justified under the documented uncertainty. Route an unresolved scheduling/limit question to AWS Support with the exact configuration and timestamps, not a proposed production retry loop.

After a separately approved change, require observed allocated/free-space state and application recovery evidence. Check incomplete imports, unknown transaction outcomes and resumed workload behavior before ending the incident. Reversing a setting cannot shrink allocated storage or undo committed work. Keep those residual obligations with named owners even if the storage graph recovers.