Capacity Planning on OCI: Shapes, Limits, and Burst

Capacity planning on OCI sits between two failure modes. Plan too tight and the estate hits walls: launches refused, autoscaling stalled, a failover that cannot provision. Plan too loose and the estate pays for insurance it never claims, idle OCPUs, oversized shapes, reservations covering workloads that no longer exist. The discipline that threads the needle has three parts: knowing the instruments OCI gives you, forecasting from measured consumption rather than instinct, and reviewing on a calendar so the plan tracks the estate instead of trailing it. This piece covers all three, as part of our series on advanced OCI operations.

The instruments, and what each is for

OCI's compute model gives the planner unusually fine grain. Flexible shapes let an instance specify OCPUs and memory independently within a family, which converts the old shape ladder problem, the workload that needs the memory of the next size up but not its cores, into a dial. Burstable instances run at a baseline fraction of their OCPUs with the ability to burst to full, priced near the baseline, which fits the long tail of services that idle for hours and spike for minutes. Autoscaling moves instance pool size against schedules or metrics, supplying elasticity for the tiers built to scale horizontally. Capacity reservations hold physical capacity in an availability domain ahead of need, turning the probabilistic question of whether the region will have the shape into a contractual one. Dedicated hosts buy whole servers for isolation or licensing geometry. Each instrument answers a different shape of uncertainty, and most estates need three or four of them deployed deliberately.

The licensing dimension deserves a sentence of its own: for Oracle workloads under BYOL, shape and core decisions are license decisions, and the cheapest technical answer is sometimes the most expensive contractual one. Sizing and licensing belong in the same conversation, which is why our assessments run them together.

Forecasting from the estate you actually run

The raw material for honest forecasting is already in the Monitoring service: utilization per instance, per pool, per database, over a year of history if the retention was configured with planning in mind. The method does not need data science. Per workload, take the trailing percentile that matters, the 95th for steady services, the peak for the batch and close cycles that define the business calendar, trend it across two or three quarters, and overlay the known future: the migration wave landing in May, the product launch in September, the country rollout in Q1. The output is a per workload demand curve, and the plan is the gap between that curve and current footprint, expressed as concrete actions with dates: resize these, reserve those, raise the limits over there.

Forecasting also exposes the estate's quiet liabilities. The instance running at 8 percent for three quarters is a resizing candidate the plan should harvest, because capacity planning and cost optimization are the same exercise read in opposite directions. The capacity freed by rightsizing the overprovisioned half of the estate routinely funds the headroom the growing half needs, and estates that run the two reviews together, as we do in optimization engagements, find the arithmetic lands near the sitewide pattern: roughly 40 percent of spend is movable once consumption is actually measured.

Headroom: limits, supply, and the failover case

Two ceilings sit above every elastic design, and neither appears in architecture diagrams. The first is the tenancy's service limits, the administrative ceilings covered in depth in service limits and quotas on OCI: an autoscaling policy that wants ten more instances at peak needs the limit headroom to grant them, and the capacity plan should drive the limit increase requests one phase ahead of the demand curve. The second is physical regional supply: limits headroom does not guarantee the availability domain has the shape in stock at the moment of scale out, and for constrained families, GPUs above all, the gap between entitled and available can be the whole plan. The planner's tools against supply risk are reservations for the must launch footprint, shape flexibility in the launch configurations so equivalents can substitute, and spreading across availability domains where the architecture allows.

Disaster recovery deserves its own line in the plan, because DR capacity is the easiest headroom to let rot. The standby region's limits and, for the critical core, its reserved capacity must track the primary's growth, reconciled quarterly and verified by provisioning tests rather than spreadsheet review. A DR plan whose capacity assumptions are two years stale is a document about a smaller estate that no longer exists.

The calendar that keeps the plan honest

A capacity plan is a forecast, and forecasts decay. The working cadence is quarterly: refresh the demand curves from the last quarter's metrics, score the previous forecast against what happened, harvest the rightsizing candidates, reconcile limits and reservations in both primary and DR regions, and retire the insurance no longer needed, the reservation held for a workload that was decommissioned, the dedicated host at 40 percent fill whose tenants could consolidate. Between quarters, the plan runs on autopilot through the scheduling and shutdown automation described in stopping idle compute on a clock, and the financial tripwires described in OCI budgets and alerts catch the demand surprises the forecast missed. Forecast, prevention, detection: three layers, one calendar.

The special cases that bend the rules

Three workload classes deserve their own paragraph in any OCI capacity plan. Exadata and the dense database shapes occupy a middle ground between cloud and hardware: elastic within the racks you have, but stepwise and lead time bound when you need another, so their planning horizon looks more like procurement than provisioning, and the demand curve needs to flag the step change quarters early. GPU capacity behaves like a commodity in shortage everywhere: entitlement, supply, and price all move, reservations matter more than anywhere else in the estate, and the honest plan sometimes includes a second region purely for accelerator availability. And the batch estate, the month end closes, the billing runs, the warehouse loads, inverts the usual logic: its capacity question is not how much but when, and the cheapest answer is usually calendar engineering, spreading the peaks rather than buying them headroom. Each of these classes punishes the generic plan, and each rewards the planner who treats it as its own small market.

A six step capacity planning loop

Who holds the pencil

Capacity planning fails organizationally before it fails technically: everyone owns a workload, nobody owns the curve. The fix is a named owner for the estate level plan, a quarterly review that actually convenes, and the four numbers on one page, demand growth, headroom per ceiling, reservation fill, and harvest captured, trending in the right directions. This is standing work, not project work, which is why it folds naturally into a managed operations arrangement, and why our OCI optimization service treats the capacity review and the cost review as a single quarterly exercise, on a fee model paid only from verified savings. Across 500+ OCI engagements and 20+ years of combined Oracle experience, the estates that never make capacity news share one habit: someone, every quarter, compares the footprint to the measured curve and acts on the difference. The instruments are good. The calendar is the discipline.