GoldenGate Microservices Architecture vs Classic: When to Use Which

Oracle GoldenGate ships in two distinct deployment architectures: the Classic Architecture (the original GGSCI-based model) and the Microservices Architecture (introduced in 18c, fully mature from 21c). Both replicate data using the same trail-file and process model under the hood, but they differ substantially in how processes are deployed, managed, and monitored. Choosing the wrong one for your use case adds unnecessary operational complexity.

The Fundamental Difference

Classic Architecture: Operational Model

In Classic, the Manager process is the parent for all Extract, Pump, and Replicat processes. You interact with the system via GGSCI (GoldenGate Software Command Interface).

# Start GGSCI
cd $GG_HOME && ./ggsci

# Typical operational commands
GGSCI> START MANAGER
GGSCI> INFO ALL
GGSCI> ADD EXTRACT EXT1, INTEGRATED TRANLOG, BEGIN NOW
GGSCI> ADD EXTTRAIL ./dirdat/lt, EXTRACT EXT1, MEGABYTES 500
GGSCI> START EXTRACT EXT1

Parameter files live in $GG_HOME/dirprm/. Reports are in $GG_HOME/dirrpt/. Everything is file-based and scriptable with shell scripts.

Why Classic Still Matters

• Heterogeneous targets — many non-Oracle target adapters (MySQL, PostgreSQL, Kafka, Hadoop) are only available or best supported in Classic installations.
• Air-gapped/on-prem environments without REST/web access preferences.
• Legacy pipelines already running Classic where migration risk outweighs benefit.
• Simpler automation when your ops team is already scripting shell + GGSCI.

Microservices Architecture: Operational Model

Microservices introduces a hierarchy of services:

Service Manager (port 9011)
  └── Deployment (e.g., "production")
        ├── Administration Service   (manages Extract/Replicat via REST)
        ├── Distribution Service     (manages Pump/path to remote trails)
        ├── Receiver Service         (receives trails from remote Distribution Service)
        └── Performance Metrics Service

Deploying a Microservices Instance

Deployments are created via oggca.sh (the Oracle GoldenGate Configuration Assistant):

$GG_HOME/bin/oggca.sh \
  -silent \
  -responseFile /tmp/ogg_deployment.rsp

Or, in OCI GoldenGate, deployments are provisioned via the OCI Console or Terraform provider — no SSH required.

Managing Processes via REST

All GGSCI operations have REST equivalents:

# List all extracts
curl -u oggadmin:Password1 \
  http://localhost:9011/services/v2/extracts

# Start an extract
curl -u oggadmin:Password1 -X PATCH \
  http://localhost:9011/services/v2/extracts/EXT1 \
  -H "Content-Type: application/json" \
  -d '{"status":"running"}'

# Get lag statistics
curl -u oggadmin:Password1 \
  http://localhost:9011/services/v2/extracts/EXT1/statistics

This makes Microservices a natural fit for infrastructure-as-code pipelines (Ansible, Terraform) and integration into broader observability stacks.

Web UI

The Service Manager exposes a browser-based dashboard at https://<host>:9011. For production environments with multiple deployments, this provides a centralised view of all process statuses and lag metrics without requiring SSH.

OCI GoldenGate: Fully Managed Microservices

OCI GoldenGate is a fully managed service running on the Microservices Architecture. Oracle manages the infrastructure, patching, and availability. You interact only via the OCI Console, REST APIs, or Terraform.

# Terraform: provision an OCI GoldenGate deployment
resource "oci_golden_gate_deployment" "gg_prod" {
  compartment_id          = var.compartment_id
  display_name            = "gg-prod-deployment"
  deployment_type         = "DATABASE_ORACLE"
  license_model           = "LICENSE_INCLUDED"
  subnet_id               = var.subnet_id
  cpu_core_count          = 2
  is_auto_scaling_enabled = true

  ogg_data {
    deployment_name = "gg-prod"
    admin_username  = "oggadmin"
    admin_password  = var.ogg_admin_password
  }
}

OCI GoldenGate connections are defined separately and attached to deployments, enabling reuse across pipelines:

resource "oci_golden_gate_connection" "source_adb" {
  compartment_id  = var.compartment_id
  connection_type = "ORACLE"
  display_name    = "source-adb-connection"
  technology_type = "ORACLE_DATABASE"
  username        = "ggadmin"
  password        = var.db_password
  connection_string = var.adb_connection_string
}

Migration from Classic to Microservices

If you are running Classic and considering migrating:

1. Do not migrate running pipelines cold — quiesce Extract, allow trail files to drain, stop Replicat cleanly.
2. Copy parameter files to the new deployment’s dirprm (they are compatible with minor syntax adjustments).
3. Re-add processes using the REST API or Web UI.
4. Restart Extract with BEGIN <SCN> from the last checkpoint SCN to avoid re-reading logs from the beginning.

-- Find the current Extract SCN before migration
SELECT EXTRACT_NAME, EXTRACT_SCN FROM GG$EXTRACT_STATUS;

Decision Framework

Use Microservices when:

• Deploying on OCI or planning to use OCI GoldenGate managed service.
• You need REST API integration for CI/CD pipelines.
• Running Oracle 19c+ as source/target.
• You want PDB-level deployment isolation in a CDB environment.

Use Classic when:

• Replicating to/from non-Oracle endpoints with Classic-only adapters.
• Operating in environments with strict security controls that disallow REST/HTTP services.
• Your team’s operational tooling is GGSCI-shell-script-based and migration costs are high.
• Running older Oracle Database versions (pre-12c) where Integrated Extract is limited.

In greenfield projects on Oracle 19c or later, Microservices is the unambiguous choice.