FAQ

Which databases does TwinCommit support?

Sources: Oracle, MySQL, SQL Server, PostgreSQL, MongoDB, IBM Db2 (LUW and z/OS), Apache Cassandra, MariaDB and SAP HANA.

Targets: all of those relational and NoSQL databases (Db2 LUW as a target), plus Snowflake, Databricks, Amazon Redshift, Google BigQuery, Azure Synapse Analytics, data lakes on Azure Data Lake Storage, Amazon S3 and Google Cloud Storage (Delta Lake, Iceberg or Parquet), Apache Spark, Apache Hive, Redis, Elasticsearch and Kafka. Any source can replicate to any target.

Does TwinCommit install anything in my source database?

No. It needs standard logging settings, such as archive logging and DATA CAPTURE CHANGES on Db2, supplemental logging on Oracle, or wal_level=logical on PostgreSQL. On PostgreSQL it creates a publication and a replication slot. It creates no triggers, tables or procedures.

What happens if TwinCommit crashes mid-transaction?

Nothing is lost or duplicated. The checkpoint is committed in the same target transaction as the data, so TwinCommit resumes from the last committed transaction. See exactly-once delivery.

Can I run TwinCommit next to my current replication tool?

Yes. Both read the log independently. Use a separate target schema during the parallel run. See the GoldenGate and IIDR migration guides.

Can one pipeline write to several targets?

A pipeline has one target. To fan out, run one pipeline per target against the same source; each keeps its own checkpoint.

Does TwinCommit replicate DDL?

It detects DDL and isolates the affected table. See schema changes.

How is TwinCommit licensed?

Per source database. The Developer edition is free for non-production use. See pricing.

Is the MCP server required?

No. It is an optional way to operate pipelines from an AI assistant. Everything it does is also available through the CLI and /status.

Where does my data go?

Only from your source to your target. TwinCommit is self-hosted and sends no data or telemetry to us.