Oracle GoldenGate is a separately licensed product, not a database option — and its licensing model is the single most common source of surprise cost for teams that adopt it for replication or zero-downtime migration. Because GoldenGate runs against source and target databases, the licence question is rarely "do we need GoldenGate?" but "how many environments, on what metric, and at which edition?" This guide sets out the buyer-side fundamentals. For the wider portfolio, start with our complete Oracle licensing guide.
What GoldenGate licenses
GoldenGate is licensed per the deployment where its capture or delivery processes run. In a classic database-to-database replication, that typically means licensing GoldenGate on both the source and the target, because GoldenGate components operate at each end. Buyers frequently budget for one side and discover the requirement to license the other during a true-up. The metric follows Oracle's standard Processor and Named User Plus models, so the same core-counting and Core Factor rules that govern the database also apply to GoldenGate processor licences.
Editions and adjacent SKUs
GoldenGate is sold in more than one form, and the names matter. Beyond the base GoldenGate product there are variants and management add-ons — for example management/monitoring tooling, and editions aligned to specific platforms or to heterogeneous (non-Oracle) sources and targets. There is also a managed cloud form, GoldenGate on Oracle Cloud Infrastructure, billed through OCI consumption rather than perpetual licences. The right SKU depends on whether replication is Oracle-to-Oracle or heterogeneous, on-premises or cloud, and whether you need the management pack.
| Scenario | Typical licensing consideration |
|---|---|
| Oracle-to-Oracle replication | GoldenGate licensed on both source and target databases |
| Heterogeneous (e.g. Oracle to non-Oracle) | A GoldenGate edition supporting the non-Oracle endpoint may be required |
| Zero-downtime migration only | Time-bounded use still requires a licence for the period; confirm terms |
| GoldenGate on OCI (managed) | Consumption-based via OCI rather than perpetual licences |
The migration trap
A frequent assumption is that using GoldenGate purely to perform a one-time, zero-downtime migration does not require a full licence because the use is temporary. That is not safe to assume. GoldenGate's use during a migration window is still use, and unless a specific time-limited entitlement or promotional term applies, the deployment must be licensed for the period it runs at each end. The defensible approach is to confirm in writing the entitlement that covers the migration, rather than relying on the idea that short-term use is free.
Buyer takeaway: The two GoldenGate cost surprises are licensing only one side of a replication pair and choosing the wrong edition for a heterogeneous or cloud topology. Map every capture and delivery endpoint to a licence before deployment, and confirm migration-window entitlements explicitly. For modelling and negotiation, see our Oracle licensing experts and the Oracle vendor hub.
Keeping GoldenGate cost under control
Three habits keep GoldenGate spend predictable. First, inventory every environment where GoldenGate processes run, including DR and test copies, because each can carry a requirement. Second, decide deliberately between perpetual on-premises licences and OCI-managed consumption based on the duration and scale of the workload — short projects often favour consumption, long-running replication often favours perpetual. Third, align the GoldenGate edition to the actual source/target mix rather than buying the broadest edition by default. Documented properly, GoldenGate becomes a budgeted line rather than an audit surprise.
Processor counting and the Core Factor
Because GoldenGate uses Oracle's Processor metric, the licensable quantity on a given server is derived the same way as for the database: count the physical cores on the host (or the capped cores where a recognised hard-partitioning boundary applies), multiply by the relevant Oracle Processor Core Factor, and round to whole licences. The implication is that GoldenGate inherits the same architectural sensitivities as the database. Running GoldenGate inside a virtualised estate that Oracle treats as soft partitioning can widen the licensable footprint in exactly the way it does for the database engine — see our VMware soft-partitioning analysis. The cleanest GoldenGate deployments sit on hosts with a clear, evidenced core boundary at both source and target.
Common questions
Do I really need GoldenGate on both ends of a replication?
In most Oracle-to-Oracle replications, GoldenGate processes run at both the capture (source) and delivery (target) sides, so both typically require licensing. Confirm the topology before assuming a single-side purchase is sufficient.
Is GoldenGate the same as Data Guard?
No. Data Guard is an Oracle Database capability for physical/logical standby, while GoldenGate is a separately licensed logical replication product supporting heterogeneous and active-active topologies. They are licensed differently and chosen for different requirements.