OCI preemptible instances are compute instances Oracle can reclaim with short notice, offered at a substantial discount to on-demand in exchange for that interruptibility. They are Oracle's equivalent of AWS Spot and Google Cloud Spot VMs: the same hardware and shapes, a much lower price, and the catch that Oracle can stop the instance when it needs the capacity back. For fault-tolerant and stateless workloads, OCI preemptible instances are one of the largest single discounts available on the platform.
This article is part of our Oracle cloud cluster. For the wider set of levers, read the complete guide to Oracle Cloud (OCI) cost optimization, the pillar this guide links up to. Preemptible compute is part of the Cut step in our See, Cut, Lock, Run method: it is a rate cut you take on the workloads that can absorb interruption.
How OCI preemptible instances work
A preemptible instance is launched with a preemptible capacity configuration. It runs like any other instance until Oracle needs the capacity, at which point it is reclaimed. The default behavior terminates the instance, though you can configure it to stop and preserve the boot volume so it can be relaunched. You get a discount against the equivalent on-demand shape, and you give up any guarantee that the instance will keep running. The trade is simple: lower price, no uptime promise.
When the discount is worth it
Preemptible instances pay off whenever the work can survive an interruption and be retried or rescheduled. That covers a wide band of real workloads, and the discount is large enough that it changes the economics of any compute-heavy, interruption-tolerant job. The question is never just price; it is whether your workload can lose a node without losing data or correctness.
Never put state you cannot lose on a preemptible instance. If reclaim means a retry, use it freely. If reclaim means corruption or data loss, do not. Everything else about preemptible cost optimization follows from that single line.
Workloads that fit
Good candidates share the same trait: they are stateless, or their state lives somewhere durable. Batch processing and data pipeline jobs that checkpoint progress. CI and build runners that simply re-run if a node disappears. Stateless web and API tiers behind a load balancer with healthy autoscaling. Rendering, transcoding, and other embarrassingly parallel work. Worker pools in a container platform that can reschedule a lost pod. In each case, losing a node is an inconvenience the system already handles, not an incident.
Workloads that do not fit
Avoid preemptible instances for anything that holds unique state or must stay up. Primary databases. Stateful singletons with no failover. Long-running jobs with no checkpointing, where reclaim throws away hours of work. Anything with a hard uptime commitment to a customer. For those, on-demand or committed capacity is the right tool, and the sibling guide on how to rightsize OCI compute shapes covers getting the on-demand portion right.
How to use them safely
Design for reclaim rather than hoping it will not happen. Run preemptible nodes behind autoscaling and a load balancer so a lost node is replaced automatically. Checkpoint long jobs so a retry resumes rather than restarts. Mix preemptible and on-demand capacity so a baseline survives even if all preemptible nodes are reclaimed at once. Watch the reclaim rate, because if it is high in your region and shape, the savings may not be worth the operational drag, and a committed shape may serve better.
Want your OCI compute mix tuned for cost and resilience?
We map which workloads can move to preemptible capacity, design the reclaim handling, and balance it against committed and on-demand so you save without risking uptime. On the performance model, you pay only from realized savings. No savings, no fee.
Book an OCI cost audit →Preemptible versus commitments
Preemptible instances and commitments are not competitors; they cover different parts of your fleet. Commitments suit the steady baseline you will run regardless. Preemptible capacity suits the elastic, interruptible layer on top. The cheapest design usually layers both: a committed baseline for what is always on, preemptible for burst and batch, and on-demand only for the brief gaps. The sibling guide on how to negotiate an Oracle Cloud commitment covers the committed layer.
| Workload | Preemptible fit |
|---|---|
| Batch and data pipelines | Strong, if checkpointed |
| CI / build runners | Strong, retries are cheap |
| Stateless web / API tier | Good, behind a load balancer |
| Primary databases | Avoid, state is unique |
| Uptime-committed services | Avoid, no run guarantee |
OCI preemptible instance behavior, reclaim notice and the discount versus on-demand reflect Oracle's published model as of May 2026. Discount percentages and reclaim mechanics change, so confirm the current figures in Oracle's documentation before sizing a design on them.
The OCI Cost Optimization Field Guide includes a workload-to-pricing-model map that shows where preemptible, committed, and on-demand each win, so you can place every workload on the cheapest model it can tolerate.
The short version
OCI preemptible instances cut compute cost sharply in exchange for interruptibility. Use them for stateless and checkpointed work behind autoscaling, never for unique state or uptime-committed services, and layer them with committed and on-demand capacity for the rest. When you want your OCI compute mix tuned for both cost and resilience by an independent team, that is part of what our OCI cost optimization service delivers.