Autonomous Database: what "autonomous" actually removes, and what it does not

Autonomous Database is the service Oracle uses to make the case for OCI, and the marketing does it a disservice by overpromising in one direction while underselling the two things that actually matter most in practice: auto-scaling and auto-stop.

What it genuinely removes

• Patching and upgrades. Applied automatically in a maintenance window with no downtime for the RAC-backed tiers.
• Backup configuration. Automatic backups with point-in-time recovery, retained for a configurable window, with no policy to write.
• Index and statistics tuning. Automatic indexing evaluates candidate indexes against your real workload and creates the ones that help. This works better than scepticism expects, and it is genuinely useful on a schema nobody has time to tune.
• Encryption and basic hardening, on by default, not optional.
• Capacity management. Auto-scaling adjusts OCPU up to three times the base within seconds, and auto-stop shuts a development database down when idle. For non-production, these two together are the real cost story: a development database that costs nothing overnight and at weekends.

What it does not remove

• Schema and query design. A badly normalised schema with no thought given to access patterns is still a badly performing database.
• Connection management. Connection pooling and the limits of your service level still apply, and an application opening a connection per request will still exhaust them.
• Understanding the execution plan. When a query is slow, you still need to look at what it does. Automatic indexing narrows the problem; it does not think for you.
• Migration effort. Getting there is the same work as any database migration.

Choosing the flavour

Transaction Processing versus Data Warehouse is a choice about default optimisations — indexing and row-store behaviour versus columnar and parallel query. Pick by workload shape; it is not easily changed later.

Serverless versus dedicated infrastructure. Serverless is the default and correct for most workloads. Dedicated gives you an isolated Exadata infrastructure, which matters for strict isolation requirements, predictable performance at the top end and specific compliance positions. It is a substantially different price point.

JSON and APEX variants exist for those specific shapes and are worth knowing about before someone builds a document store on top of a relational configuration.

The operational things to set up anyway

Autonomous does not mean unattended:

• Private endpoint, always. Autonomous Database can be created with a public endpoint and an access control list. Use a private endpoint in a VCN subnet and disable public access, then reach it through your existing network — the same posture as private endpoints in Azure and for the same reasons.
• Customer-managed keys in OCI Vault where your compliance line requires control of the key, rather than the Oracle-managed default.
• Database audit to OCI Logging, with retention in a separate compartment that the database team cannot delete from.
• Test the restore. Automatic backups are not a recovery plan until someone has restored one into a new instance and connected an application to it. Do this once a quarter.
• Monitor the auto-scaling ceiling. Auto-scale is capped at three times the base OCPU. A workload that hits the ceiling regularly needs a larger base, and the symptom is latency rather than an error.

Where it fits

For an organisation with Oracle Database workloads and Oracle support contracts, Autonomous plus the Support Rewards programme is often the strongest financial argument OCI has — see why OCI bills look different. The licensing conversation dominates, and it is worth having with someone who knows your agreement.

For a greenfield application with no Oracle history, the honest answer is that PostgreSQL on any provider is a more portable default, with a larger pool of engineers and no licensing dimension. Autonomous earns its place when you are already in the Oracle ecosystem, when the automatic tuning is removing work you genuinely cannot staff, or when the auto-stop economics for a large non-production estate are decisive.

That last case is underrated. A development and test estate of twenty databases that cost nothing outside working hours is a real saving, and it is the easiest Autonomous deployment to justify.

We assess this alongside the other database options in the migration phase of cloud engagements.

What to do this week

If you already run Autonomous, check two things: whether the endpoint is private, and when someone last restored a backup into a fresh instance. If you are evaluating it, price a non-production estate with auto-stop enabled — that number is usually more persuasive than the production comparison.