Sizing Autonomous Database on OCI comes down to two decisions: the base ECPU count you provision and how you use compute auto scaling. The database bills compute by ECPU, the elastic compute unit, continuously against the base count, with storage charged separately on provisioned capacity. Because the base is paid around the clock, oversizing it for peak demand is the most common waste, and the fix is to set the base for the steady load and enable compute auto scaling so the database can burst up to a multiple of the base only when demand rises, paying for the extra ECPU just while it is in use. For non production databases, scheduled stop and start pauses ECPU billing entirely outside working hours. Together these three moves cut database compute cost without touching performance during the hours that matter.
Autonomous Database is often the largest single line in an OCI database estate, so getting the ECPU model right pays back quickly. Here is how the levers work.
How does ECPU billing work?
Autonomous Database measures compute in ECPU and bills it continuously against the base count you set, independent of storage, which is charged on provisioned capacity. The base ECPU count is therefore the number that drives steady cost: a base of sixteen ECPU billed around the clock costs the same whether the database is at full load or nearly idle. Storage scales separately, so the compute decision and the storage decision are made independently. The flexible ECPU model is finer grained than older OCPU sizing, which lets you provision closer to real need rather than rounding up to a coarse shape, and the flexible compute shapes elsewhere on OCI follow the same principle of precise sizing.
How should you set the base and use auto scaling?
The winning pattern separates the steady load from the peaks. Set the base ECPU count to cover the steady, persistent load, the level the database sits at most of the time, then enable compute auto scaling, which lets Autonomous Database burst above the base up to a multiple of it when demand rises and bills the additional ECPU only while in use.
- Right size the base. Provision the base for the steady load, not the peak. Paying for peak capacity around the clock when peaks are occasional is the single most common Autonomous Database waste.
- Enable compute auto scaling. Let the database absorb spikes on demand instead of carrying permanent headroom. You pay for burst ECPU only during the burst.
- Match storage to need. Provision storage to real data volume with sensible growth headroom, reviewed alongside compute rather than once at creation.
The trap is the reverse: sizing the base to the busiest hour of the month so the database never needs to scale. That guarantees you pay peak rates continuously for capacity used a fraction of the time, which is exactly what auto scaling exists to avoid.
What about non production databases?
Development, test, staging, and reporting databases rarely need to run outside working hours, yet they often bill their base ECPU continuously because no one stops them. Stopping an Autonomous Database instance pauses ECPU compute billing while storage keeps billing, so a scheduled stop overnight and at weekends removes a large share of the compute cost for any database that is genuinely idle then. Automating stop and start on a schedule turns a manual chore into a standing saving, and because production is untouched there is no performance trade off. This pairs naturally with the broader idle resource discipline in the OCI optimization review playbook.
A Fortune 500 enterprise ran a fleet of Autonomous Databases with bases sized to peak and auto scaling disabled, plus a set of development databases running around the clock. Lowering each production base to the steady load and enabling compute auto scaling to absorb peaks, then scheduling the non production databases to stop overnight and at weekends, cut the Autonomous Database compute line by a clear double digit percentage with no measured impact on production performance. Figures are verified against billing data and anonymised.
Where ECPU sizing fits the OCI database picture
ECPU sizing is one half of Autonomous Database economics; the licensing model is the other. Whether you run license included or bring your own license materially changes the per ECPU cost, covered in license included versus BYOL on OCI, and the question of which Oracle workloads belong on OCI at all is covered in when Oracle workloads belong on OCI. The full estate context, including flexible compute shapes and storage, lives in the OCI cost optimization guide, and the cross cloud database comparison sits in the cross cloud cost optimization guide.
Frequently asked questions
How is Autonomous Database billed by ECPU?
What does compute auto scaling do?
Can you stop an Autonomous Database to save money?
Right size your Autonomous Database estate
We help enterprises set ECPU bases to real load, tune auto scaling, and schedule non production databases so OCI database compute matches demand. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk. We take zero provider commissions and answer only to you.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.