SynchDB 1.4: Oracle CDB Support and Secured FDW Snapshots

Aug 19

By · Updated Aug 19

postgresqldatabase replicationoraclesynchdbchange data capture

Heterogeneous database replication is an architectural staple for teams offloading analytics or migrating production workloads to PostgreSQL. The release of SynchDB 1.4 addresses two critical operational friction points in enterprise replication pipelines: first-class support for Oracle Container Databases (CDB/PDB) across all ingestion mechanisms, and end-to-end network encryption for initial Foreign Data Wrapper (FDW) snapshot transfers.

This update enhances resilience and security for enterprise deployments where streaming data into PostgreSQL or IvorySQL must meet strict compliance and network isolation requirements.

Architecture Overview

SynchDB operates as a native PostgreSQL extension, orchestrating initial bulk data ingestion alongside continuous Change Data Capture (CDC).

+-------------------------------------------------------------+
|                    Source Data Layer                        |
|  +--------------------+             +--------------------+  |
|  | Oracle CDB/PDB     |             | MySQL / PostgreSQL |  |
|  | (e.g. FREE/PDB1)   |             | Sources            |  |
|  +---------+----------+             +---------+----------+  |
+--------|---|----------------------------------|-------------+
         |   |                                  |
Snapshot |   | CDC Logs                Snapshot | TLS
(Wallet) |   | (Debezium / OLR)                 | (FDW)
         v   v                                  v
+-------------------------------------------------------------+
|                     SynchDB 1.4 Engine                      |
|  +-------------------------------------------------------+  |
|  |  FDW Snapshot Module (Secured via TLS / Wallet)       |  |
|  +-------------------------------------------------------+  |
|  +-------------------------------------------------------+  |
|  |  Embedded Debezium Engine / Openlog Replicator        |  |
|  +-------------------------------------------------------+  |
+------------------------------+------------------------------+
                               |
                               v
+-------------------------------------------------------------+
|               Target PostgreSQL / IvorySQL                  |
+-------------------------------------------------------------+

Building resilient data pipelines requires careful operational isolation and streaming guarantees, as discussed in our articles on Building Reliable Microservices and backend architecture patterns in Engineering Notes.

Multi-Tenant Oracle Container Database (CDB/PDB) Support

Oracle Container Databases isolate tenant pluggable databases (PDBs) inside a parent container (CDB). Previous database replication tools required complex custom TNS routing or forced unified administrative credentials across containers.

SynchDB 1.4 expands Oracle CDB/PDB support across all three of its Oracle replication pathways:

  1. Change Data Capture (CDC) via the embedded Debezium engine.
  2. Initial Snapshots using oracle_fdw.
  3. Log-Based Replication using Openlog Replicator (OLR).

Targeting a pluggable database is straightforward: supply the target service in standard CDB/PDB notation (for example, FREE/FREEPDB1). SynchDB automatically handles authentication and connects directly to the underlying PDB service. This path is validated against modern Oracle engines including Oracle 23ai.

-- Registering an Oracle CDB/PDB source in SynchDB 1.4
SELECT synchdb_add_conninfo(
    'oracle_tenant_connector', 'oracle-host.internal', 1521,
    'c##synch_user', 'read-from-a-secret-manager',
    'FREE/FREEPDB1', 'postgres', 'null', 'null', 'oracle'
);

TLS-Secured FDW Snapshots via synchdb_add_fdw_conninfo()

Prior to SynchDB 1.4, initial snapshot loading performed via foreign data wrappers lacked native encryption parameter configuration. While continuous streaming CDC channels could be secured, historical bulk table loads over FDW ran over unencrypted plaintext connections unless wrapped in external IPSec or SSH tunnels.

SynchDB 1.4 introduces synchdb_add_fdw_conninfo(), allowing backend engineers to attach encryption connection parameters directly to foreign wrappers:

  • TLS Encryption for MySQL and PostgreSQL snapshot sources.
  • Oracle Wallet security parameters for Oracle and Openlog Replicator snapshot sources.

The extension exposes synchdb_add_fdw_conninfo() for this configuration. Its installed SQL signature accepts a connector name plus four text parameters; use the version-matched SynchDB documentation to map those parameters to TLS mode, certificate, key, root certificate, or Oracle Wallet settings. Avoid copying positional calls across releases without checking the installed extension definition.

This ensures full in-transit confidentiality across the entire lifecycle of a replication pipeline—from initial bulk snapshot ingestion to real-time delta propagation.

Runtime Observability and Performance Adjustments

SynchDB 1.4 adds the ability to adjust the Debezium engine log level at runtime without interrupting active CDC streaming connectors. Previously, increasing verbosity to diagnose schema drift or lag spikes required restarting the connector service, risking backlog build-up.

-- Dynamically change log level to DEBUG for troubleshooting
SELECT synchdb_set_dbz_loglevel('oracle_tenant_connector', 'DEBUG');

The release also upgrades the embedded Debezium engine from 2.6.2.Final to 3.5.2.Final and reports fixes for crashes under sustained replication load, a data-converter crash, and an Oracle parser startup conflict. Treat those as reasons to test the upgrade under your own workload, not as a guarantee that backpressure is solved.

Operational Tradeoffs

While SynchDB 1.4 simplifies heterogeneous replication, engineers should evaluate key operational tradeoffs:

  • Oracle Wallet Maintenance: Utilizing Oracle Wallet for encrypted snapshots avoids inline credentials, but requires persistent filesystem certificate mounting and key rotation procedures across database nodes.
  • Snapshot Resource Pressure: Initial snapshots compete with live CDC for source, network, and target capacity. Measure throughput and replication lag during a production-sized rehearsal.
  • PDB Service Privileges: Grant only the Oracle permissions required by the chosen Debezium, FDW, or OLR path; the three paths do not have identical privilege requirements.

When NOT to Use SynchDB

  • Single-Database Homogeneous Replication: If you are replicating strictly between PostgreSQL instances, native logical replication or physical streaming replication (PostgreSQL High Availability) provides better native integration and lower system overhead.
  • Stateless Event Ingestion: If downstream consumer applications only require event notifications rather than strict relational state synchronization in PostgreSQL, standard event streaming brokers (e.g., Apache Kafka or NATS) are better suited.

Common Mistakes

  • Assuming Historical FDW Snapshots Were Encrypted: Relying on SynchDB versions prior to 1.4 for initial snapshot loading across public networks without external VPN tunnels left snapshot data unencrypted.
  • Omitted PDB Service Specifications: Specifying only the container database name instead of the combined CDB/PDB string (e.g., using FREE instead of FREE/FREEPDB1) causes connector initialization failures during service resolution.

Conclusion

SynchDB 1.4 closes an important encryption gap for initial snapshots and extends CDB/PDB handling across its Oracle paths. It is still an extension with native, JVM, FDW, and source-database dependencies, so production adoption should follow a staged snapshot-and-CDC rehearsal with observable lag, restart, and certificate-rotation tests.

References

>