Oracle Goldengate Licensing Guide

How Oracle GoldenGate licensing works:

• Oracle Goldengate can be licensed under the named user, license, and processor metric.
• You must license both the source and target hosts.

Oracle Goldengate Licensing

Oracle GoldenGate is a powerful real-time data replication platform; however, its licensing model can be complex and costly if not managed effectively.

Organizations must license GoldenGate carefully – typically per processor core – on both source and target systems to remain compliant and avoid unbudgeted fees.

This guide explains Oracle GoldenGate licensing models, common pitfalls (like virtualization and cloud missteps), best practices, and strategies to optimize costs and ensure compliance in enterprise environments.

Overview of Oracle GoldenGate and Licensing Challenges

Oracle GoldenGate is a high-performance data replication solution; however, understanding its licensing is crucial to avoid costly compliance issues.

Oracle GoldenGate enables real-time data integration, migration, and disaster recovery across diverse databases and platforms, delivering significant benefits for business continuity.

However, GoldenGate’s licensing is not straightforward – it is not bundled with Oracle Database and requires separate licenses that must be carefully calculated.

Many organizations underestimate these requirements, leading to compliance violations or unexpected expenses during Oracle audits.

Both IT and procurement teams need to grasp GoldenGate’s licensing rules to deploy it cost-effectively and remain audit-ready.

Oracle GoldenGate Licensing Metrics and Calculation

Oracle licenses GoldenGate primarily on a Processor basis (per processor core, adjusted by a core factor). Unlike some Oracle products, Named User Plus (NUP) licensing is generally not allowed for GoldenGate in production, so you should plan for processor-based licenses.

The number of licenses required is determined by counting the processor cores on each server where GoldenGate will run, and then applying Oracle’s Core Factor multiplier (which accounts for different CPU types’ performance).

Core Factor Table: Oracle provides a core factor table that assigns a multiplier to each processor type. For example, Intel and AMD x86 processors have a core factor of 0.5, meaning two cores count as one license, whereas some older or higher-performance chips (like IBM POWER) have a factor of 1.0 (one license per core).

Specialized Oracle SPARC T-series chips have a factor as low as 0.25. Accurately applying these factors is crucial.

License Count Example: If GoldenGate runs on a server with 16 Intel Xeon cores, the core factor 0.5 means 16 × 0.5 = 8 GoldenGate processor licenses are required for that server.

Important: Oracle’s policy is that each environment (source and target) where GoldenGate is installed must be licensed. If you replicate data between two servers, you need to count the cores and license GoldenGate on both.

This can effectively double the license count for a single end-to-end replication setup (one set of licenses for the source machine and one for the target machine). Neglecting to license one side is a common mistake that can lead to compliance issues.

GoldenGate Licensing in Virtualized and Cloud Environments

Licensing GoldenGate becomes more challenging in virtualized on-premises data centers and cloud deployments, due to the different rules Oracle enforces:

Virtualized Environments (e.g., VMware): Oracle generally requires you to license all physical cores in a virtualization cluster if any VM in that cluster is running GoldenGate.

This means even if you allocate GoldenGate to a small VM, the entire underlying hardware cluster might need to be fully licensed.

For example, a VMware cluster with three hosts, each with 16 cores (48 cores total), hosting just one small GoldenGate VM (say 4 vCPUs) would still require licensing all 48 cores (using the core factor).

In this case, 48 cores × 0.5 = 24 GoldenGate licenses needed, not just the two licenses that a four vCPU VM might suggest. The lack of soft partitioning recognition means Oracle treats the whole cluster as the licensable unit – a costly surprise if not planned for.

Consider physically isolating GoldenGate to a dedicated host or using Oracle-approved hard partitioning technologies if you need to limit licensing scope in virtualized environments.

Public Cloud (AWS/Azure): In public clouds, Oracle uses a different rule because hardware cores aren’t directly visible. For Amazon Web Services (EC2), Microsoft Azure, and similar clouds, Oracle’s formula is that every two virtual CPUs (vCPUs) count as one processor license.

The Oracle core factor table does not apply in cloud scenarios – it’s a simple 2-for-1 rule. For example, if you deploy GoldenGate on an AWS instance with 16 vCPUs, you need 16 ÷ 2 = 8 GoldenGate licenses.

It’s crucial not to mistakenly apply the 0.5 core factor in the cloud; doing so would under-license by half. Note also that you must license each cloud VM or service where GoldenGate runs – similar to on-prem, both “ends” in a cloud-based replication must be covered (e.g., an AWS source and an Azure target each need licensing based on their vCPUs).

Oracle Cloud Infrastructure (OCI): Oracle offers GoldenGate as a managed cloud service on OCI with two models: a subscription model (where you pay per OCPU hour for Oracle’s managed GoldenGate service) or Bring Your Own License (BYOL), where you use your existing GoldenGate processor licenses on OCI compute.

For BYOL, Oracle applies the same 2 vCPU = 1 license rule to cloud cores (Oracle’s “OCPU” is effectively equivalent to one full core, or two vCPUs). The managed GoldenGate Cloud Service on OCI is an alternative to self-managing licenses; it charges by usage (for example, roughly $0.32 per OCPU hour, which equates to about $0.64 per hour for a 2-vCPU resource).

Enterprises should compare the cost of using GoldenGate Cloud Service (opex) versus licensing GoldenGate on cloud VMs via BYOL (capex + support) to decide the most cost-effective approach.

Common Pitfalls and Compliance Risks

Oracle GoldenGate’s licensing complexity means several common pitfalls can lead to non-compliance or budget overruns:

• Not Licensing All Components (Source/Target): A frequent mistake is to license GoldenGate on only one side of a replication (e.g., the source database server), assuming that covers the whole setup. In reality, both source and target servers must be fully licensed for GoldenGate. If GoldenGate is running on or even installed on a server, that server requires a license. Forgetting this doubles the risk of an audit penalty since any unlicensed GoldenGate installation is out of compliance.
• Incorrect Core Factor Application: Misunderstanding Oracle’s core factor table can lead to under-counting licenses. For example, counting an AMD EPYC core at 0.25 instead of the correct 0.5 would mean buying half the licenses required. Such miscalculations are often caught during audits and can result in steep back-license fees. Always use the official Oracle core factor table for the exact processor models in your servers.
• Virtualization Compliance Gaps: As noted, running GoldenGate on a small VM in a large VMware or Hyper-V cluster without licensing the entire cluster poses a significant compliance risk. Oracle’s audit team will typically consider the entire cluster’s cores as licensable if they find GoldenGate on any node. This “virtual sprawl” issue has caught many companies off guard, resulting in huge true-up costs. The safe approach is to assume no core isolation in standard virtualization: license all physical cores or segregate GoldenGate to a contained environment.
• Cloud Licensing Errors: Treating cloud vCPUs like on-prem cores is another pitfall. Some organizations mistakenly apply on-premises licensing logic to cloud deployments – for instance, thinking that 16 vCPUs only require four licenses using a 0.25 factor, which is incorrect. Oracle’s cloud policy is less granular and can require more licenses than expected if not understood correctly. Always use the two vCPU = 1 license rule for AWS/Azure, and remember that each cloud instance must be licensed (unless you’re using Oracle’s own GoldenGate service, where licensing is built into the hourly rate).
• Unlicensed Disaster Recovery Setup: If you set up GoldenGate for high availability or disaster recovery, such as maintaining a live standby database, please note that the standby environment is not exempt from licensing considerations. Even if the target is only used for failover, if GoldenGate is actively replicating to it, Oracle requires it to be licensed (unless you’ve negotiated a specific exemption). Some companies mistakenly assume a DR site is passive and doesn’t require licenses — that’s not the case with GoldenGate, especially when replication is running.

License Restrictions and Special Cases

Oracle GoldenGate licensing comes with some important restrictions and unique cases that enterprises should keep in mind:

• Processor-Only Licensing: Oracle GoldenGate must be licensed per processor. Oracle typically does not allow Named User Plus licensing for GoldenGate (except perhaps in rare, non-production scenarios). This means that even if you have a limited number of users or just one integration use case, you cannot avoid processor licensing. Budget accordingly for processor licenses; the Named User metric, which is available for many Oracle products, cannot usually be used to reduce GoldenGate costs.
• Separate Editions for Different Sources/Targets: GoldenGate is sold in different editions depending on the databases or systems involved. If you are replicating between an Oracle database and a non-Oracle database (say Oracle to SQL Server), you will need to purchase GoldenGate for Oracle Database licenses for the Oracle side and GoldenGate for Non-Oracle Database licenses for the SQL Server side. The processors count the licenses for each edition on those servers. The list price is generally the same for Oracle vs. non-Oracle editions (around $17,500 per processor), effectively doubling your cost for heterogeneous replication because you need two sets of licenses. Plan for this when justifying the project ROI – the flexibility to replicate beyond Oracle comes at a significant licensing expense. There are also specialized GoldenGate versions for certain platforms (e.g., GoldenGate for Mainframe, which enables integration with mainframe databases like IBM DB2 z/OS and is extremely expensive, costing roughly $ 100,000 per processor license due to the niche use case).
• No Free Standby Usage: Oracle does not provide a free or reduced-cost standby license for GoldenGate. If you install GoldenGate for a disaster recovery site or passive standby system, that installation requires a full license unless your contract explicitly states otherwise. Unlike some database features that have limited-use rights for standby, GoldenGate treats every active instance equally for licensing. Make sure any failover environments running GoldenGate are accounted for in your license count.
• GoldenGate for Big Data (One-Sided Licensing): One notable exception in licensing scope is that Oracle GoldenGate for Big Data targets. GoldenGate for Big Data is an adapter-based version that delivers data to big data systems (Hadoop, Kafka, NoSQL, etc.). Oracle’s policy for this specific edition is that you only need to license the source database side when using GoldenGate for Big Data. The big data target cluster nodes do not require GoldenGate licenses. For example, if you are streaming Oracle DB changes into a Kafka cluster using GoldenGate for Big Data, only the Oracle source database server cores need licensing. This one-sided licensing rule is a beneficial exception, but it applies strictly to the Big Data adapters scenario. Always confirm current rules for any specialized GoldenGate edition you use.
• Active Data Guard Rights Included: A GoldenGate license for Oracle Database includes a restricted-use license for Oracle Active Data Guard on that same database server. In practice, this means that if you have licensed GoldenGate on an Oracle Database Enterprise Edition, you are permitted to use Active Data Guard for a physical standby on that database without requiring a separate Active Data Guard license. This inclusion is useful if you supplement GoldenGate replication with an ADG standby or are evaluating both technologies. Keep in mind that the Active Data Guard use under this rule is only for the databases that have GoldenGate licensed, and this benefit is per Oracle’s current policy – always check your license agreement for the exact terms of any included features.

Best Practices for Managing GoldenGate Licenses

To optimize costs and reduce compliance risk, organizations should implement strong internal management practices for Oracle GoldenGate licensing:

• Document Everything: Maintain detailed records of your GoldenGate deployments, including where the software is installed, which databases (source/target) are involved, the core counts of each server (or vCPUs for cloud VMs), and the licenses you have purchased. Keep copies of Oracle license agreements, proofs of entitlement, and calculations of how you arrived at the number of licenses. This documentation should be kept up to date as environments change. In an audit, having “audit-ready” documentation that matches deployments to entitlements is invaluable and can streamline the audit process.
• Perform Regular Internal Audits: Don’t wait for Oracle to audit you. Proactively review your GoldenGate usage at least annually (if not quarterly) to ensure you are within your licensed limits. Check that new GoldenGate instances haven’t been spun up without proper licensing, and that any decommissioned systems are noted so you might re-harvest those licenses. Regular internal audits can catch misconfigurations (like an admin accidentally running GoldenGate on an unlicensed server) before they become costly problems. It’s better to self-correct early than to pay penalties later.
• Train Teams on Licensing Rules: Ensure that both the technical teams deploying GoldenGate and the asset management/procurement teams understand Oracle’s GoldenGate licensing policies. A clear internal policy should exist: for example, if a DBA wants to use GoldenGate for a new project, they must involve the licensing team to verify sufficient licenses are in place or budgeted. Educate staff on key rules, such as “every GoldenGate installation must be licensed” and “in VMware, we license the whole cluster” – to prevent well-meaning mistakes.
• Mind the Virtual and Cloud Policies: Incorporate Oracle’s virtualization and cloud licensing rules into your infrastructure planning. If using VMware or other virtualization for GoldenGate, consider isolating GoldenGate to a dedicated cluster or node to contain license requirements. For cloud deployments, incorporate the 2 vCPU-per-license rule into your cost estimates. Use cloud tagging or management tools to track where GoldenGate is running. If you leverage Oracle’s GoldenGate Service on OCI, monitor usage to avoid surprise bills, and ensure you’re not accidentally “double-paying” (e.g., don’t leave on-prem licenses idle if you switch to cloud subscription – consider re-using them via BYOL or negotiating a reduction).
• Engage Experts for Complex Scenarios: For complicated architectures, such as large-scale heterogeneous replication, mainframe integration, or a mix of on-premises and cloud solutions, consider consulting an Oracle licensing expert or advisor. They can help verify your license position, suggest architecture tweaks to minimize costs (for example, pointing out if you could use GoldenGate for Big Data one-sided licensing for certain use cases), and assist in negotiations with Oracle. The cost of expert advice is often far less than the consequences of a licensing mistake in an enterprise environment.

Oracle GoldenGate Licensing Costs and Examples

Oracle GoldenGate is a high-end enterprise software and is priced accordingly. Below are some indicative list prices (as of 2025) for GoldenGate licenses (one-time perpetual license fees, not including annual support):

Notes: These are list prices per Oracle’s official price list. Oracle typically also specifies a Named User Plus price (for example, $350 per NUP for GoldenGate), but as discussed, using NUP for GoldenGate is usually not practical due to Oracle’s policies and minimums. Annual support cost is 22% of the license price, so for a $17,500 license, support is about $3,850 per year (per processor). Support is mandatory if you want access to updates and technical assistance, so factor this recurring cost into your budget. Oracle often will offer discounts off the list price during negotiations (depending on the size of the deal, your relationship, and timing), so the actual price paid could be lower after a volume discount or as part of a larger enterprise agreement.

Real-World Example: Imagine an on-premises setup with GoldenGate replicating between two Oracle databases. Server A has 8 cores and Server B has 8 cores, both utilizing Intel CPUs (with a 0.5 core factor). Each server needs 8 × 0.5 = 4 licenses, for a total of 8 processor licenses. At $17,500 each, that’s a total list price of $140,000. Annual support would add roughly $30,800 per year. Suppose this were a cross-platform replication (Oracle to SQL Server, for instance). In that case, you’d need four licenses of GoldenGate for Oracle and 4 of GoldenGate for Non-Oracle, effectively doubling the cost to $280,000 (plus support). This simplistic scenario illustrates how costs can grow with GoldenGate – especially as you add more cores or additional heterogeneous targets – and why careful planning and optimization (such as limiting GoldenGate to only necessary systems or exploring Oracle’s cloud service for elastic use cases) is important.

Recommendations

• Thoroughly assess your GoldenGate needs and scope before deployment to avoid over-licensing or surprises – know exactly which servers and how many cores will run GoldenGate.
• Always license both source and target environments where GoldenGate is installed. Include any DR or standby systems in the license count if GoldenGate will be actively replicating data to them.
• Use Oracle’s official core factor table and cloud policies for all calculations. Double-check core counts and applicable factors or vCPU rules for each hardware platform or cloud instance to ensure the license count is accurate the first time.
• For virtualization, isolate GoldenGate if possible. If you use VMware or a similar platform, consider dedicating a smaller cluster or host to GoldenGate to avoid licensing an entire large cluster. Ensure your team understands that putting GoldenGate on a broadly shared VM farm can incur a license for every core in that farm.
• Leverage BYOL and cloud options wisely: If you have spare on-prem GoldenGate licenses, use them in the cloud via BYOL to save cost. Conversely, if your GoldenGate usage is seasonal or project-based, Oracle’s GoldenGate Cloud Service (pay-as-you-go) might be more cost-effective than buying perpetual licenses.
• Negotiate with Oracle: Don’t hesitate to negotiate pricing and terms. Oracle might offer discounts if GoldenGate is purchased alongside other products or if you’re making a strategic investment. Also, clarify any included rights (such as Active Data Guard usage) during negotiations and ensure they are documented in writing.
• Implement continuous compliance checks: Make GoldenGate licensing a part of your software asset management program. Set up alerts or reviews for any new GoldenGate deployments, and monitor any infrastructure changes (such as adding cores to a server or relocating GoldenGate to a new host) that could impact licensing.
• Plan for support renewals: Budget for the 22% annual support cost, and review if all GoldenGate instances are still needed before renewing support each year. If some replication setups are retired, you might be able to terminate support on those licenses (or re-purpose licenses elsewhere).
• Seek expert guidance for complex setups: In mergers, cloud migrations, or large-scale projects involving GoldenGate, involve Oracle licensing specialists or consultants to validate your approach. This can prevent costly missteps and also help you optimize license usage (for example, by highlighting if a different Oracle solution or a license-free alternative might suffice for part of the requirement).

GoldenGate Licensing Checklist (5 Key Actions)

1. Inventory Your GoldenGate Deployments: Create a list of all servers, VMs, and cloud instances where Oracle GoldenGate is installed or planned. Note the CPU core counts (or vCPUs) and processor types for each to use in license calculations.
2. Calculate Required Licenses Accurately: For each deployment, apply the Oracle core factor (for on-premises hardware) or the cloud vCPU rule (2 vCPUs = 1 license) to determine the number of processor licenses required. Double-check that both ends of each replication stream (source and target) are included.
3. Verify License Entitlements: Cross-check your calculations with the licenses you have purchased. Ensure you have the correct type of GoldenGate licenses for each use case (e.g., GoldenGate for Oracle, GoldenGate for Non-Oracle, Big Data adapters, etc.). Document any gaps and address them proactively (either by procuring additional licenses or re-architecting to reduce usage).
4. Document and Archive Proof: Maintain a central folder (and preferably a living document) with all GoldenGate license proofs, Oracle contracts, core factor tables used, and calculation worksheets. Update this documentation whenever there is a change (new servers, upgrades, migrations). In the event of an Oracle audit, this is the evidence you will use to demonstrate compliance.
5. Review Compliance Periodically: Set a regular schedule (e.g., quarterly or before any Oracle audit quarter) to review GoldenGate usage against licenses. Include checks for virtualization (ensure no one moved GoldenGate into an unlicensed cluster) and cloud (ensure any new cloud deployments follow the BYOL rules or are accounted as service subscriptions). This ongoing vigilance will catch issues early and maintain continuous compliance.

FAQ

Q1: How do I determine the number of Oracle GoldenGate licenses I need?
A1: Count all the physical processor cores on each server (or nodes in a cluster) where GoldenGate will be installed, then apply Oracle’s core factor for those processors (most Intel/AMD chips use 0.5). The result is the number of processor licenses required for that machine. Do this for every source and target server. For cloud deployments, use the rule that each set of 2 vCPUs counts as one license. For example, a server with 8 cores (x86) requires four licenses (8 × 0.5), and a cloud VM with 8 vCPUs also requires four licenses (8 ÷ 2). Always round up fractional results to whole licenses if applicable.

Q2: Do I need to license GoldenGate on both the source and target systems?
A2: Yes. Oracle requires any server or environment where GoldenGate is running to be licensed. If you are replicating data from Database A to Database B, and GoldenGate is installed on both ends (which it typically is, to capture from A and apply to B), then both A and B must be fully licensed for GoldenGate. This also applies to multi-hop setups or hub-and-spoke topologies – each server that runs a GoldenGate Extract, Pump, or Replicat process needs a license. There is no “primary only” licensing concept for GoldenGate; even a target or standby system using GoldenGate must be licensed.

Q3: How is GoldenGate licensing handled in virtualized environments like VMware?
A3: In virtualized environments, Oracle’s policy is strict: if GoldenGate runs on any virtual machine in a cluster, you typically must license all physical cores in that entire cluster. It doesn’t matter if the GoldenGate VM only uses a few vCPUs – Oracle will treat the whole cluster as a licensable unit (because Oracle does not recognize standard VMware or similar hypervisors for sub-capacity licensing). To manage this, you can either dedicate a smaller cluster or physical host for GoldenGate workloads or explore Oracle-approved hard partitioning methods that Oracle recognizes (such as Oracle VM with pinned pCPU or certain hypervisor technologies that Oracle has certified). Always review the latest Oracle partitioning policy if you plan to deploy GoldenGate on virtualized infrastructure to avoid licensing more cores than necessary.

Q4: Can we use Named User Plus licensing for Oracle GoldenGate to save cost?
A4: In practice, no for most scenarios. While Oracle’s price list might show a Named User Plus price for GoldenGate, Oracle generally mandates that GoldenGate be licensed per processor for production environments. Even if NUP is theoretically available, the minimum user counts and restrictions usually make it non-viable. For instance, Oracle often requires a high minimum number of Named Users per processor (typically 25 per processor for many products), which for GoldenGate could end up equivalent or more expensive than processor licensing, and Oracle sales/support may not allow it if GoldenGate is enabling an integration (rather than human end-users). Almost all enterprises license GoldenGate by processor. Consider NUP only in very specific cases (non-production or low-volume scenarios) and obtain explicit Written approval from Oracle, but expect processor licensing to be the norm.

Q5: Does a GoldenGate license include the right to use Active Data Guard or other add-ons?
A5: Yes, Oracle GoldenGate for Oracle Database licenses include a limited-use license of Oracle Active Data Guard for the same databases that GoldenGate is supporting. This means if you’ve licensed GoldenGate on an Oracle DB, you can implement Active Data Guard (for a physical standby database) on that source/target without buying a separate ADG license for that DB. It’s a bundled benefit designed to enable the use of both replication technologies simultaneously. Note that this is a restricted use right – ADG can only be used for those specific databases under the GoldenGate license, and only as long as you have a valid GoldenGate license and support. Other add-ons, such as Oracle XStream (an API for streaming changes out of the Oracle Database), are also included with GoldenGate licenses for Oracle DB. However, GoldenGate itself is not included with an Oracle Database license – it remains a separate product purchase. Always confirm the latest included features in Oracle’s GoldenGate licensing documentation, as these policies can evolve.

Do you want to know more about our Oracle License Management Services?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit