Autonomous Database Auto Scaling

Auto scaling is one of the features that makes Autonomous Database genuinely different from a database you size once and live with. When it is enabled, the database can automatically expand its compute up to three times the base allocation when demand rises, and contract again when demand falls, and you are billed for the additional capacity only during the hours it is actually consumed. That changes how you should think about sizing, because you no longer have to provision for the peak. The catch is that auto scaling rewards understanding. Teams that grasp how it interacts with the base get reliable performance at a low cost, while teams that treat it as either a magic fix or an unnecessary extra tend to overpay or get caught short.

How auto scaling actually works

Auto scaling operates around the base compute allocation you set, measured in ECPUs. With auto scaling enabled, the database can draw on up to three times that base when the workload demands it, scaling up to meet the load and scaling back down as it eases, with no downtime and no manual intervention. You pay the base rate for the base capacity all the time, and you pay for the additional capacity only for the hours it is used, averaged over the billing period. The practical effect is that a database sized with a modest base and auto scaling enabled can handle a surge three times its normal load without anyone touching it, and without paying for that surge capacity during the long stretches when it is not needed.

This is fundamentally a cost shaping mechanism. It lets you separate the capacity you need most of the time, which sets your floor cost, from the capacity you need occasionally, which you pay for only on demand. Understanding that separation is the key to using it well, because the whole point is to keep the always on base low while staying protected against peaks.

When to enable it

The short answer is almost always, because auto scaling provides protection against being caught short at very little downside, and for any workload that is not perfectly flat it provides real savings as well. A workload with variable demand, busy during the day and quiet at night, busy at month end and quiet otherwise, is the ideal case, because the base covers the quiet periods cheaply and auto scaling covers the busy ones without paying for them continuously. Even a workload that is fairly steady benefits from having auto scaling enabled as insurance, because it absorbs the occasional unexpected spike rather than letting it degrade performance.

The only situation where auto scaling adds little is a workload that is genuinely flat and predictable, where the base can be set exactly to the need and there are no peaks to absorb, but even then enabling it costs nothing when it is not triggered and provides a safety margin. As a default, enabling auto scaling and sizing the base for the normal load is the right starting posture for almost every database, as covered in our guide to sizing Autonomous Database correctly.

The relationship between base and auto scaling

The table captures the most useful diagnostic in the whole topic. Auto scaling behaviour is a signal about whether the base is right. A database that is constantly scaling, especially one frequently hitting three times its base, is telling you the base is too low and that you are paying surge rates as a matter of routine, which is more expensive than simply raising the base. A database that never scales despite a workload with obvious peaks may have a base set higher than it needs. Reading this signal regularly is how you keep both cost and performance in balance.

Reading scaling behaviour

Because auto scaling behaviour is so informative, watching it is a core part of running an Autonomous Database well. The platform exposes how much compute the database is using against its allocation, and the pattern over a typical week tells you most of what you need to know. A healthy pattern shows the database sitting near its base for normal periods and rising into the auto scaling range during identifiable peaks, then returning to base. An unhealthy pattern shows either constant elevation, which means the base is too low, or a flat line well below the base, which means the base is too high.

The discipline is to review this pattern periodically rather than setting the base once and forgetting it, because workloads change over time as data grows and usage shifts. A base that was right at migration may be wrong a year later, and the auto scaling pattern is the early warning that it has drifted. This kind of ongoing observation is exactly what our cost optimization practice does to keep estates efficient, and it is the sort of thing that quietly saves money when it is done consistently.

Auto scaling and cost control

Auto scaling is a cost control feature, but only when the base is set sensibly, because the two work together. Setting a low base and relying on auto scaling for everything sounds economical but is not, because surge capacity is priced to discourage using it as your normal capacity, so a database that lives in its auto scaling range costs more than one with an appropriate base. Conversely, setting a high base to avoid scaling defeats the purpose, because you pay for that high base every hour whether you use it or not. The economical configuration is a base that matches the normal load with auto scaling enabled to cover the genuine peaks above it.

This is why sizing and auto scaling are really one decision rather than two, and why the auto scaling pattern feeds directly back into the sizing review. Together with the habit of stopping idle non production databases, getting this balance right is one of the larger levers in keeping an Autonomous Database estate economical, and it sits alongside the licensing position as a primary driver of cost.

A practical approach to auto scaling

Bringing it together

Auto scaling is a feature that rewards a little understanding with a lot of value. Enabled on a database whose base is sized for the normal load, it absorbs peaks without paying for them continuously, protects against unexpected surges, and gives you a clear diagnostic signal about whether the base is right. The mistakes to avoid are relying on it instead of a sensible base, which costs more than it saves, and leaving it off out of caution, which removes both the protection and the savings. Treat sizing and auto scaling as one decision, watch the pattern, and adjust as the workload evolves. The companion guides on sizing, performance tuning and shared versus dedicated complete the picture, and the pillar guide to Autonomous Database on OCI sets it in context. When you want the base, the scaling and the cost kept in balance over time, our Autonomous Database solution covers it end to end.