Oracle Walks Back Rigid Patching Policy, Giving Cloud Database Customers the Release Flexibility They’ve Been Demanding
If you’ve ever been in the middle of a carefully orchestrated EBS certification cycle only to discover that Oracle’s cloud infrastructure insists on provisioning your new database with a release update you haven’t tested yet, you know the frustration. On October 14, 2026, Oracle quietly announced a policy change that addresses one of the most persistent pain points for enterprise DBAs running databases on OCI: Flexible Software Release Selection is now available across Exadata Database Service and Base Database Service.
This isn’t just a minor tweak. It represents a meaningful shift in Oracle’s approach to balancing its security-first patching philosophy with the real-world change management realities that govern enterprise database operations.
What’s Changing?
Under the new policy, lifecycle operations — including provisioning, patching, migrations, and business continuity operations — will continue to default to the latest available Database and Grid Infrastructure release updates. That part hasn’t changed, and it shouldn’t surprise anyone familiar with Oracle’s long-standing position on running the most current, most secure software.
What has changed is what happens next. Customers can now self-service select up to two previous release updates (N-1 or N-2) directly through the OCI console or API. The only requirement is acknowledging a message that confirms they understand they’re opting for a release that isn’t the latest. No Service Request. No waiting. No back-and-forth with support.
For organizations that need to go even further back — earlier than the N-2 threshold — the option still exists, but it requires an approved Service Request. And there’s one notable constraint: for Oracle Database 19c, exception requests are limited to release 19.25 or later. Anything older than 19.25 is off the table entirely.
Where Does This Apply?
The scope of this policy is broad, covering the core OCI database deployment models that most enterprises rely on:
- Exadata Database Service on Dedicated Infrastructure
- Exadata Database Service on Exascale Infrastructure
- Exadata Database Service on Cloud@Customer
- Base Database Service
Critically, this applies to new lifecycle operations only. Existing databases and systems are not automatically upgraded or affected by this change. If you’re currently running a specific release update, it stays where it is. The flexibility kicks in when you perform a new provisioning, apply a patch, execute a migration, or run a DR failover operation.
Why This Matters — and Why Now
To understand the significance, you need to look at what came before. Since June 2026, Oracle had implemented a more restrictive policy that aggressively pushed the latest release updates as the default — and in many cases, the only — option for lifecycle operations. While the intent was sound (ensuring customers run the most secure and well-supported software), the execution created real friction.
Enterprise environments don’t operate in a vacuum. Database release updates need to be validated against application stacks, tested in non-production environments, and coordinated with vendor certification timelines. This is especially true for Oracle E-Business Suite (EBS) environments, where a new database release update can’t simply be adopted until it’s been certified and tested against the specific EBS version and configuration in use.
The feedback from customers — particularly those managing EBS deployments with tightly coordinated testing schedules — was clear: the rigid approach was creating operational risk, not reducing it. Forcing teams to adopt untested release updates during provisioning or DR operations undermined the very stability that careful change management is designed to protect.
Oracle’s response with this updated policy strikes a pragmatic balance. The latest release remains the default and the recommended path. But the acknowledgment that enterprises need a runway — a window to validate and adopt new releases on their own schedule — is a welcome and overdue concession.
Practical Takeaways for Oracle Professionals
If you’re an Oracle DBA or cloud architect managing OCI database services, here’s what you should do right now:
- Review your current release update strategy. Understand which release updates you’re running today and which ones your applications are certified against. The N-1/N-2 self-service window gives you breathing room, but only if you know where you stand.
- Update your change management documentation. If your runbooks or DR playbooks assume that provisioning or failover will always use the latest release, update them to reflect the new selection capability — and document which release you intend to target.
- Plan for the 19.25 floor. If you’re still on Oracle Database 19c and running a release older than 19.25, be aware that this is now the hard lower bound for exception requests. If you haven’t patched to at least 19.25, prioritize that work.
- Leverage the self-service option proactively. Don’t wait until a DR event or an urgent provisioning request to discover your options. Test the release selection workflow in your non-production environments now so your team is comfortable with it when it matters.
- Stay engaged with Oracle’s release calendar. The N-1/N-2 window is relative to the current latest release. As Oracle publishes new release updates quarterly, your available self-service options will shift. Build a cadence for tracking these changes.
This policy update is a clear signal that Oracle is listening to its enterprise customer base — and that pragmatism can coexist with a security-first philosophy. For Oracle professionals who have been navigating the tension between cloud automation and enterprise change control, this is a genuinely positive development. Use the flexibility wisely, and don’t let it become an excuse to defer patching indefinitely. The default is still the latest release for a reason.