Limits

This page lists what TwinCommit does not support, and the constraints to design around.

All sources

• Every replicated table needs a primary key (or, on PostgreSQL, REPLICA IDENTITY FULL).
• Schema changes are detected, not propagated. See schema changes.
• Each pipeline applies in source commit order over one apply session. Split very high-volume schemas into several pipelines to scale out.
• TwinCommit must be the only writer to replicated target tables.

Db2

• No DPF (multi-partition) databases, column-organized tables, range-partitioned tables or MDC tables.
• LOB, XML, DECFLOAT and GRAPHIC columns must be excluded.
• Database code page must be 1208 (UTF-8).

Oracle

• LONG and LONG RAW are not supported; LOBs up to 16 MiB per value.
• Hybrid columnar compression is not supported.

SQL Server

• Memory-optimized tables are not supported; sql_variant, hierarchyid and spatial types must be excluded.

MySQL and MariaDB

• The binlog must be ROW format with binlog_row_image = FULL.
• MEMORY, BLACKHOLE, ColumnStore and Spider tables are not captured.

MongoDB

• A replica set or sharded cluster is required; standalone servers are not supported.
• Time-series and capped collections are not captured.

Apache Cassandra

• A reader must run on every node.
• Counter tables and materialized views are not captured.
• There are no multi-partition transactions; each mutation or logged batch is its own unit.

SAP HANA

• log_mode must be normal. Virtual tables and calculation views are not captured.

Non-transactional targets

• Cassandra, Redis and Elasticsearch give effectively-once results: a batch may be re-sent after a crash, and idempotent writes make the replay a no-op.
• On Redis Cluster, a source transaction spanning several hash slots is not atomic for readers.

Transactions

• A transaction larger than max_txn_memory_bytes needs that much free space in spill_dir until it commits.
• Lag includes the time a transaction stays open on the source, because nothing is applied before commit.