Autonomous Database Shared vs Dedicated

When you provision Autonomous Database on OCI, one of the first decisions the platform asks you to make is whether to run on shared infrastructure or dedicated infrastructure. It sounds like a minor configuration toggle, but it is one of the more consequential choices in the whole adoption, because it sets the isolation model, the degree of control you have over maintenance, the way the service scales, and a good part of the cost. Teams that choose without understanding the difference often end up either paying for isolation they do not need or discovering too late that the model they picked cannot give them the control a regulator expects. This guide explains what each model actually is, where each one wins, and how to decide.

What shared infrastructure actually means

Shared Autonomous Database, sometimes called the serverless deployment, places your database on Exadata infrastructure that Oracle owns and operates and that is shared across many tenants, with strong logical isolation keeping each customer separated from the others. You never see the underlying hardware, you never schedule a patch, and you provision a database in minutes by choosing a workload type, a compute size and a storage size. Oracle handles everything beneath the database itself, including the Exadata platform, the patching cadence and the capacity planning that keeps the shared pool able to absorb demand.

The appeal of the shared model is speed and simplicity. There is nothing to stand up before you create your first database, scaling compute and storage is an online operation you perform whenever you like, and you can stop a database entirely when it is idle so that you pay only for storage while it sleeps. For the large majority of workloads, development environments, departmental applications, new builds and most production systems, the shared model is the sensible default because it delivers the autonomous experience with the least friction.

What dedicated infrastructure actually means

Dedicated Autonomous Database gives your organisation Exadata infrastructure reserved entirely for you within OCI, which Oracle still operates but which no other tenant shares. On top of that reserved infrastructure you create Autonomous Container Databases, and within those you create the Autonomous Databases your applications use. This extra layering is the price of the additional control, and it is control that matters in specific situations. You decide the patching schedule rather than accepting Oracle's, you get complete tenant isolation at the hardware level, and you can run a private database cloud inside OCI with policies you set.

The dedicated model suits regulated industries that must demonstrate physical isolation, large estates that want to consolidate many databases onto infrastructure they govern, and organisations that need to align maintenance windows with their own change management calendar rather than Oracle's. It is more involved to set up and it carries a higher floor cost because you are committing to infrastructure, so it rewards scale and specific requirements rather than convenience.

The two models side by side

Isolation, the question that usually decides it

For many organisations the choice comes down to isolation. The shared model provides robust logical separation that satisfies the security requirements of the vast majority of workloads, and Oracle's design keeps tenants firmly apart even though they sit on common infrastructure. That is enough for most. Where it is not enough is in environments where a regulator, a contract or an internal policy demands that the infrastructure itself is not shared with any other party, and in those cases dedicated is the answer because the Exadata infrastructure is reserved for you alone.

The mistake to avoid is assuming you need hardware isolation when a careful read of your obligations would show that strong logical isolation already meets them. Paying for dedicated to satisfy a requirement that shared already satisfies is a common and expensive misunderstanding. The honest way to settle it is to read the actual control, not the folklore around it, and to map it to what each model provides. This is exactly the kind of question our consulting and advisory work resolves before money is committed.

Control over maintenance

The second dimension where the models genuinely differ is control over maintenance. On shared infrastructure Oracle decides when patches are applied, within published maintenance windows, and you accept that schedule in exchange for never having to think about it. For most teams that is a benefit, because patching is the kind of toil they were trying to escape. For some teams, particularly those with rigid change freezes, complex application certification cycles or regulatory reporting tied to specific dates, the ability to control exactly when maintenance happens is worth the additional cost and complexity of dedicated, where you set the windows yourself.

If your organisation has a mature change management process that everything must flow through, dedicated lets the database respect it. If your organisation would rather not manage patching at all, shared is the better fit. Neither is universally right, and the answer depends on how your change control actually operates in practice rather than how the policy document describes it.

Scale and consolidation

Scale changes the economics. A single database or a handful of them almost always belongs on shared infrastructure, because the entry cost is low and the elasticity is excellent. A large estate of many databases is where dedicated starts to make sense, because reserving infrastructure and consolidating many databases onto it can be more economical than running each one separately, and it gives the organisation a private database cloud with consistent governance. The crossover point depends on the number of databases, their sizes and how much of the reserved capacity you can actually use, which ties directly back to sizing.

Getting the sizing right is what determines whether dedicated pays off, because reserved capacity you do not use is pure waste, while well planned consolidation can be very efficient. Our guide to sizing Autonomous Database correctly covers the method, and the auto scaling behaviour is relevant in both models because it governs how each database absorbs peaks within its allocation.

Cost shape, not just cost

It is tempting to ask simply which model is cheaper, but the better question is which cost shape fits your situation. Shared has a low entry point and a pay for what you allocate model, with the powerful option to stop idle databases and pay only for storage, which makes it extremely efficient for variable and intermittent workloads. Dedicated has a higher floor because you commit to infrastructure, but that floor can deliver a lower unit cost once you consolidate enough databases onto it, and it gives predictable spending for a large stable estate. The bring your own licence option applies to both and is often the single largest cost lever, which is why the licensing position belongs in the conversation from the start.

Because licensing interacts so heavily with the economics of either model, the deployment choice and the licensing choice should be made together rather than in sequence. The cost control habits that keep either model efficient are covered in our wider Autonomous Database material and in the cost guidance for the platform, and the licensing side is where independent expertise pays for itself many times over.

A framework for choosing

The practical recommendation

For most organisations the right path is to begin on shared infrastructure, get value quickly, and learn how the workload behaves before considering whether any of it justifies dedicated. The shared model gives the full autonomous experience with the least commitment, and it is reversible in the sense that you can move workloads to dedicated later if a real requirement emerges. Reaching for dedicated first, on the assumption that it must be more capable because it is more involved, is the pattern that leads to paying for isolation and control that the workload never needed.

Where dedicated is genuinely warranted, by a regulatory isolation requirement, a strict change control regime or a large estate to consolidate, it is a powerful option that brings a private database cloud experience to OCI. The skill is in telling the two situations apart honestly, and that is a judgement that benefits from someone who has made the call across many estates. When you want that decision made on evidence rather than assumption, our Autonomous Database solution covers the deployment choice, the sizing and the ongoing management together, and the broader pillar guide on Oracle Autonomous Database on OCI puts this decision in the context of the others you will face.