Real-time replication,
straight from the log.
TwinCommit reads the transaction log of Oracle, MySQL, SQL Server, PostgreSQL, MongoDB, Db2 and more, and delivers every committed change exactly once and in order to Snowflake, Databricks, Synapse, data lakes, Kafka and 15 other targets. No triggers. No agents. One binary.
Modern alternative to Oracle GoldenGate and IBM IIDR.
<1s p99
commit-to-target latency
1.2M rows/sec
sustained apply per pipeline
0 triggers
or capture tables on the source
Exactly once
commit-ordered delivery
All 15 of the most widely used databases, plus Synapse, cloud data lakes, Spark, Hive and Kafka
Why TwinCommit
Replication that just keeps its promises.
Built by database engineers who have run log-based CDC on systems that cannot lose a single transaction.
Zero source footprint
Reads the database log directly. No triggers, capture tables, shadow tables or stored procedures, ever.
Exactly-once, by construction
The checkpoint commits in the same target transaction as the data. Kill -9 at any moment and resume without loss or duplicates.
Commit-ordered apply
Changes are buffered per transaction and applied at commit, in order. Rollbacks and savepoint rollbacks never reach the target.
Table-level fault isolation
A LOAD or ALTER on one table marks just that table broken. Everything else keeps flowing until you re-snapshot it.
Huge transactions, flat memory
Month-end batches spill to disk past a configurable threshold and still apply atomically.
One binary. Any platform.
No JVM, no manager, no agents. Runs on a VM, in Docker or on Kubernetes with the official Helm chart.
How it works
Four commands from zero to live.
Pipelines are plain YAML you can keep in Git. No GUI to click through, no manager process to babysit.
- 01
Check
twincommit checkVerifies logging, permissions and table settings, and prints the exact fix for anything missing.
- 02
Snapshot
twincommit snapshotCopies each table under a brief share lock and records the precise log position.
- 03
Stream
twincommit runStreams every committed change from that position, exactly once, in commit order.
- 04
Verify
twincommit verifyCompares source and target row counts and checksums while production keeps running.
source:
type: db2
database: PRODDB
user: $${DB2_USER}
password: $${DB2_PASSWORD}
target:
type: databricks
host: adb-123.azuredatabricks.net
warehouse: replication-wh
catalog: prod
tables:
- source: BILLING.LEDGER
- source: SALES.ORDERS
exclude_columns: [CARD_PAN]
batch:
max_rows: 5000
flush_interval: 1sRun replication by asking for it.
The TwinCommit MCP server plugs your pipelines into Claude, GitHub Copilot, Cursor and any MCP client. Check lag, explain errors, re-snapshot tables and verify data in plain English. It installs with one command.
- 01Install
- 02Connect
- 03Ask
$ claude mcp add twincommit -- npx -y @twincommit/mcp{
"mcpServers": {
"twincommit": {
"command": "npx",
"args": ["-y", "@twincommit/mcp"],
"env": { "TWINCOMMIT_URL": "http://localhost:9108" }
}
}
}$ code --add-mcp '{"name":"twincommit","command":"npx","args":["-y","@twincommit/mcp"]}'// ~/.cursor/mcp.json
{
"mcpServers": {
"twincommit": { "command": "npx", "args": ["-y", "@twincommit/mcp"] }
}
}- ✓ Read-only by default; writes need explicit opt-in
- ✓ Row values redacted unless you allow them
- ✓ Talks to your local /status endpoint only
- ✓ 10 tools, from lag history to re-snapshot
txn 991204, with 2.1M rows on BILLING.LEDGER. It's spilling to disk, so it will apply as one unit at commit. Nothing is broken.max_txn_memory_bytes to 1 GiB for this pipeline?twincommit_caught_up…Any source. Any target.
9 sources × 22 targets, one engine.
Every route uses the same pipeline format, the same guarantees and the same operational tooling.
Switching is simple
Coming from GoldenGate or IIDR?
Run TwinCommit in parallel, verify, and cut over. Your source database doesn't change at all.
TwinCommit vs
Oracle GoldenGate
No extract, pump and replicat processes to orchestrate. One process reads the log, buffers transactions and applies them.
Read the comparison →TwinCommit vs
IBM InfoSphere Data Replication (IIDR)
The Db2 log reader decodes row images natively, handles savepoint rollbacks and survives log archive rotation, with no capture tables.
Read the comparison →TwinCommit vs
IBM InfoSphere CDC
Download, `twincommit check`, `twincommit snapshot`, `twincommit run`.
Read the comparison →TwinCommit vs
Debezium
Write directly to PostgreSQL, SQL Server, Databricks, Hive or Snowflake, or to Kafka when you want events.
Read the comparison →TwinCommit vs
Qlik Replicate
Version, review and promote replication config through Git like any other infrastructure.
Read the comparison →TwinCommit vs
Fivetran HVR
Runs entirely inside your environment. No data passes through a third-party cloud.
Read the comparison →Frequently asked questions
What is TwinCommit?
+
TwinCommit is log-based change data capture (CDC) and real-time database replication software. It reads the transaction log of Oracle, MySQL, SQL Server, PostgreSQL, MongoDB, IBM Db2, MariaDB, SAP HANA and Apache Cassandra and applies every committed change, exactly once and in commit order, to any of those plus Snowflake, Databricks, Google BigQuery, Amazon Redshift, Redis, Elasticsearch, Apache Spark, Apache Hive and Kafka.
How is TwinCommit different from Oracle GoldenGate or IBM IIDR?
+
TwinCommit is a single binary with no agents, triggers or capture tables, YAML pipelines you can keep in Git, native lakehouse targets, flat per-database pricing, and a built-in MCP server so you can operate replication from Claude, Copilot or Cursor.
Does TwinCommit install anything in my source database?
+
No. TwinCommit relies on standard logging settings such as archive logging and DATA CAPTURE CHANGES on Db2, or supplemental logging on Oracle. It creates no triggers, tables or procedures on the source.
What does exactly-once delivery mean in TwinCommit?
+
The replication checkpoint is written in the same target transaction as the data. If the process crashes at any point it resumes from the last committed checkpoint, so no transaction is lost or applied twice.
What is the TwinCommit MCP server?
+
It is a Model Context Protocol server that exposes TwinCommit pipelines to AI assistants. With one command you can ask Claude, GitHub Copilot or Cursor to check lag, explain an error, restart a pipeline or re-snapshot a table.
Which databases does TwinCommit support?
+
TwinCommit covers the 15 most widely used databases: Oracle, MySQL, Microsoft SQL Server, PostgreSQL, MongoDB, Snowflake, Redis, IBM Db2, Elasticsearch, Databricks, Apache Cassandra, MariaDB, SAP HANA, Amazon Redshift and Google BigQuery, plus 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 and Apache Kafka.
Where does TwinCommit run?
+
Anywhere Linux runs: a VM, bare metal, Docker or Kubernetes via the official Helm chart. It is self-hosted, so your data never leaves your network.
Replicate your first table in five minutes.
Download the free Developer edition, or have one of our replication engineers walk you through a migration plan.