Oracle Database Third-Party Support: Coverage, Versions & What It Costs (2026)

Oracle Database Version Support Matrix

The first question most IT teams ask is whether their specific Oracle Database version is covered by independent support. The answer is almost always yes — independent support providers typically cover a wider range of versions than Oracle itself officially supports, including versions Oracle has placed on Sustaining Engineering or declared end of life.

What Oracle Database TPS Covers

GoVendorFree's Oracle Database TPS coverage mirrors Oracle Premier Support's operational scope for everything except version upgrades and Oracle-issued patches. For the vast majority of enterprise DB environments, the practical coverage gap is smaller than Oracle implies.

Included in GoVendorFree Oracle DB TPS

• Break/fix support — Diagnostic and resolution support for Oracle Database errors, crashes, performance degradation, and configuration issues
• Performance tuning — Query optimisation, index review, execution plan analysis, wait event diagnosis
• Interoperability support — Assistance with Oracle DB integration with third-party middleware, application servers, and operating systems
• Regulatory and compliance updates — Tax, statutory, and compliance updates relevant to Oracle DB-driven applications
• Backup and recovery guidance — RMAN configuration, recovery strategy, data guard setup and troubleshooting
• Upgrade advisory — If you eventually decide to upgrade DB versions, we support the planning and testing process
• 24/7 availability — 15-minute response SLA for critical issues, named engineer model, follow-the-sun coverage

Not Included

• New Oracle-issued patch releases (Oracle CPU patches, PSU patches) — see the patching section below
• Oracle Database version upgrades — you're on TPS specifically because you're not upgrading
• Oracle Cloud-hosted DB services (Oracle Autonomous DB, ExaCS) — TPS applies to on-premise and self-managed deployments

The Patching Question — What Really Happens

The most frequent objection to Oracle Database TPS is the patching question: "Without Oracle support, we won't receive Oracle's Critical Patch Updates (CPUs). How do you handle security vulnerabilities?"

This is a legitimate question, and it deserves a precise answer rather than a dismissal.

How GoVendorFree Handles Oracle DB Vulnerabilities

When Oracle releases a CPU (Critical Patch Update) that addresses Oracle Database vulnerabilities, our engineers analyse the specific CVEs involved and apply the appropriate response through one or more of the following mechanisms:

• Configuration controls — Many Oracle DB vulnerabilities are exploitable only under specific configurations that can be changed. Hardening the configuration mitigates the vulnerability without requiring Oracle's patch.
• Network and access controls — Vulnerabilities that require network access can be mitigated by firewall rules, network segmentation, and access control lists at the OS and network level.
• Compensating controls — SIEM alerts, intrusion detection signatures, and monitoring rules that detect and contain exploitation attempts for specific CVEs.
• Alternative patches — For some Oracle DB vulnerabilities, patches exist in related open-source components or OS layers that address the same vulnerability vector.

Oracle Database Security Under TPS: A Realistic Assessment

Oracle's security narrative around TPS is designed to generate anxiety. The actual risk profile for most enterprise Oracle Database environments under TPS is materially lower than Oracle implies, for the following reasons:

Reason 1: Most Oracle DB Vulnerabilities Are Not Exploitable in Well-Segmented Environments

The majority of Oracle Database CVEs are rated critical or high based on the assumption that the database is internet-exposed or accessible to unprivileged network users. In a properly architected enterprise environment — where Oracle DB sits in an isolated network tier accessible only by application servers — the actual exploitability of most CVEs is minimal.

Reason 2: Oracle's Patches Don't Eliminate Risk — They Shift It

Oracle CPUs address specific CVEs — but they also introduce change. Production database patching carries its own risks: application regression, performance changes, compatibility issues. Many enterprise IT teams apply Oracle CPUs months or years after release anyway, maintaining a significant vulnerability window even with active Oracle support.

Reason 3: The Comparison Should Be to Current Practice, Not Theoretical Ideal

The correct comparison is not "TPS vs. perfect Oracle patching". It's "TPS vs. what you're actually doing today". If you're on Oracle 12c R2 Sustaining Engineering and haven't applied a CPU in 18 months, TPS with proactive security management is materially better than your current practice — not worse.

Oracle Database TPS: Cost Comparison

Oracle Database support is priced at 22% of the full licence value per year. For significant Oracle DB estates, this is a large and often growing number. Here's what the TPS savings look like across typical enterprise DB environments:

Ranges reflect variation in discount history, edition mix, and licence values. GoVendorFree provides precise modelling based on your specific contract. Request a free assessment for your numbers.

Common Oracle Database TPS Scenarios

Scenario 1: Oracle DB 19c — Ahead of Premier Support Expiry

Oracle DB 19c is the most widely deployed Oracle Database version and was in Premier Support through 2024. With Extended Support now in play, organisations running 19c face an escalating cost curve. Moving to TPS ahead of your next Extended Support renewal locks in savings now and removes the Extended Support fee escalation from your planning horizon.

Scenario 2: Oracle DB 12c R2 on Sustaining Engineering

Paying Oracle's full 22% for Sustaining Engineering is the clearest TPS case. You're receiving no new patches, no new fixes — only access to patches Oracle already released. GoVendorFree TPS provides better active support at 60–68% less cost.

Scenario 3: Oracle DB Supporting EBS/JDE/PeopleSoft — Migration Planned

Oracle EBS clients planning a cloud migration or EBS 12.2 upgrade often need a 2–4 year bridge before the migration completes. TPS provides that bridge — keeping your DB and application estate covered while the migration is planned, tested, and executed on your timeline, not Oracle's.

Scenario 4: Heavily Customised Oracle DB with Compliance Requirements

Healthcare, financial services, and manufacturing clients often have Oracle DB estates where version stability is a regulatory requirement. GxP-validated environments, PRA-assessed systems, and ISO 27001-scoped DB estates all benefit from the version lock that TPS provides — your support provider maintains your current validated state rather than pushing upgrades that would require re-validation.

How the Oracle DB TPS Transition Works

The transition from Oracle support to GoVendorFree TPS for Oracle Database typically follows this timeline:

1. Week 1–2: Assessment and documentation. We document your Oracle DB estate: versions, instance topology, RAC/Data Guard configuration, known issues, OS and middleware stack, and any compliance-specific requirements. This document becomes your GoVendorFree support baseline.
2. Week 2–3: Proposal, legal review, and contract signature. We provide a formal proposal based on your documented estate. Your team reviews the TPS agreement. We review your Oracle licence terms for any clauses requiring attention.
3. Week 3–5: Oracle notice period and transition. You (or we) give Oracle the required notice under your support contract. There's typically an overlap period where Oracle and GoVendorFree coverage runs concurrently.
4. Week 5–6: Go-live. GoVendorFree TPS goes fully live. Named Oracle DBA engineer assigned to your account. 15-minute critical response SLA active.

Related Resources