Sizing Autonomous Database Correctly

One of the genuine advantages of Autonomous Database is that you do not have to size it perfectly before you understand the workload, because both compute and storage can be changed online without downtime. That flexibility is real and valuable, but it leads some teams to treat sizing as something they can ignore, which is a mistake. The base allocation you choose sets the floor under your monthly bill and the baseline for performance, and auto scaling sets the ceiling. Get the base too high and you pay every hour for capacity you never use. Get it too low and you lean on auto scaling constantly, which costs more than a sensible base would have. This guide explains how to size deliberately rather than by guesswork.

The units you are sizing

Autonomous Database compute is measured in ECPUs in the current model, which replaced the older OCPU model, and storage is measured in terabytes. ECPUs map to processing capacity, and the number you allocate is your base. Storage is allocated separately and also scales online. The two are largely independent, so a database can be compute heavy and storage light or the reverse, and you size each to the workload rather than buying them in a fixed ratio. Understanding that the base ECPU count is the lever that most directly drives both cost and steady state performance is the starting point for sizing well.

It helps to think of the base as the capacity you are willing to pay for all the time, and auto scaling as the capacity you are willing to pay for occasionally when demand spikes. That framing keeps the two decisions distinct and stops teams from inflating the base to cover peaks that auto scaling should handle.

Start from measurement, not intuition

The single most common sizing error is choosing a base from intuition or from the size of the old system rather than from measurement. An existing Oracle Database has utilisation data, and the right base for its replacement is derived from how much processing it actually uses during a normal busy period, not from how many cores the old server happened to have. Servers are frequently over provisioned, so copying the old core count straight across usually carries the over provisioning into the new platform and inflates the bill from day one.

For a new build with no historical data, the honest approach is to start modestly, enable auto scaling to protect against being caught short, and let the first weeks of real usage tell you where the base should sit. Autonomous Database makes this safe because adjusting the base later is an online operation. Starting modest and growing into the right size is almost always cheaper than starting large and trying to justify shrinking later, which rarely happens because nobody wants to risk it.

How auto scaling changes the sizing question

Auto scaling lets Autonomous Database expand its compute automatically up to three times the base allocation when demand rises, then contract again when it falls, and you pay for the additional capacity only during the hours it is actually used. This fundamentally changes how you should think about the base, because you no longer need to size for the peak. You size the base for the normal working load and let auto scaling absorb the spikes, which is far more economical than provisioning a high base that sits mostly idle so that it can cope with an occasional surge.

The practical implication is that a database with spiky demand should have a relatively low base and rely on auto scaling, while a database with steady demand should have a base close to its actual need and rarely trigger scaling at all. Watching how often auto scaling engages tells you whether the base is right. Constant scaling means the base is too low, and never scaling on a spiky workload may mean the base is higher than it needs to be. The mechanics are covered in detail in our guide to Autonomous Database auto scaling.

A sizing method that works

Sizing storage

Storage sizing is more straightforward than compute because it tracks data volume rather than processing demand, but it still deserves attention. You allocate storage to hold the current data plus headroom for growth, and because it scales online you do not need to over allocate against a distant future. A common pattern is to size storage for the current data plus a sensible margin for the next planning period and then expand as the data actually grows. Over allocating storage years ahead is a quieter form of the same over provisioning that affects compute, and it is just as avoidable now that scaling is online.

It is worth remembering that storage and compute are billed separately, so a database that holds a large volume of data but processes it lightly should not be given a high compute base just because its storage is large. The two dimensions are independent and should be sized independently against their respective demands.

Development and test sizing

Non production databases are where sizing discipline pays off most visibly, because development and test instances rarely need the capacity of production and almost never need to run around the clock. Sizing them small and, crucially, stopping them when they are not in use turns what could be a significant cost into a minor one. A stopped Autonomous Database bills only for storage, so a development database that runs during working hours and stops overnight and at weekends costs a fraction of one left running continuously at production size.

The habit to build is treating non production sizing as a separate decision from production rather than copying the production size across, and pairing modest sizing with automated stopping schedules. These two habits together are often the largest single saving available in an Autonomous Database estate, and they cost nothing to adopt. The wider set of techniques sits in our cost guidance and in the work our cost optimization practice does on verified savings.

The over provisioning trap

The reason sizing matters so much is that over provisioning is quiet. An oversized base does not announce itself with errors or alerts, it simply appears on the bill every month as capacity that was paid for and not used, and because the database performs perfectly well nobody is prompted to question it. This is how Autonomous Database estates drift into costing far more than they need to, one oversized base at a time, with no single decision that looks wrong in isolation. The only defence is the discipline of sizing from measurement and reviewing utilisation regularly.

A regular review that compares the base allocation against actual utilisation, and that checks how often auto scaling is engaging, will surface oversized databases that can be trimmed. This is ordinary day two hygiene that pays for itself, and it is exactly the kind of review that benefits from an outside perspective because the people running the database every day stop seeing the cost they have grown used to.

A sizing checklist

Bringing it together

Sizing Autonomous Database well is not about predicting the future perfectly, because the online scaling means you do not have to. It is about setting a base from real measurement, letting auto scaling absorb the peaks so you do not pay for them all the time, and reviewing utilisation so that over provisioning does not quietly accumulate. Done this way, sizing gives you predictable cost and reliable performance, and it leaves the elasticity available for the times you actually need it. The related decisions on auto scaling, on shared versus dedicated and on performance tuning all interact with sizing, and the pillar guide to Autonomous Database on OCI sets them in context. When you want the sizing done from evidence and kept right over time, our Autonomous Database solution covers it end to end.