Write strategies

Gluesync never writes one row at a time. For target databases, each entity uses either batch SQL or a native bulk mechanism. Batch mode is the default; bulk mode can optionally be enabled per entity when the target agent supports it — it is always a deliberate user decision.

Overview

Gluesync groups incoming rows into chunks before writing them to the target. The choice is not between "single-row inserts" and "bulk load": it is always between:

Batch mode, which sends SQL batch operations in configurable chunks.
Bulk mode, which uses database-native loading mechanisms for higher throughput.

Use the write strategy that matches the target’s capacity and the workload you are running. In practice, batch mode is simpler and gentler on the database, while bulk mode is faster for large snapshot loads and other high-volume writes.

Batch mode

Batch mode is the default write path. Gluesync accumulates rows and applies them in chunks using SQL batch operations. The chunk size is controlled by the maxWriteBatchSize configuration property on the target agent.

Typical defaults are:

1000 for most targets
100000 for Informix

Batch mode is a good fit when:

You want predictable load on the target.
The target does not support bulk loading for the current entity.
You need to tune memory usage or transaction size more conservatively.

Larger batches usually mean fewer network round-trips and better throughput, but they also use more memory and can hold locks for longer. Smaller batches reduce pressure on the target and on Gluesync, but they increase write overhead.

Tune maxWriteBatchSize when you need to balance throughput against memory and lock contention. Increase it for stable, high-bandwidth environments. Decrease it when the target is sensitive to long-running transactions or when the agent starts to buffer too much data.

Bulk mode

Bulk mode uses native database mechanisms instead of plain SQL batch execution. The exact implementation depends on the target agent:

PostgreSQL uses COPY in binary format through a staging table, so writes do not go through single-row SQL.
Informix uses a staging table plus a bulk SQL generator.
Other target agents implement their own native bulk path.

Bulk mode can optionally be enabled per entity using two independent flags — enabling one does not automatically enable the other:

useBulkOperationsWhileSnapshot — optionally enables bulk during the initial snapshot phase.
useBulkOperationsDuringCDC — optionally enables bulk during ongoing CDC replication.

These flags are independent because snapshot and CDC have different write patterns. Some target agents support both, while others support only one of them.

When bulk mode is active, Gluesync creates a staging table in its schema on the target database. A staging table is a temporary working table that receives the incoming rows first, then hands them off to the final target table through the database’s native bulk/apply logic. This keeps the target apply step fast and makes it easier for the agent to stage, validate, and merge large datasets efficiently.

When to use each

Criterion	Batch mode	Bulk mode	Recommendation	Best fit
Throughput	Good	Highest	Choose bulk when the target can absorb a large ingest window and you want maximum speed.	Large snapshots and other high-volume loads
Latency	Lower setup cost per write, but more round-trips than bulk	Best for large transfers, less efficient for tiny writes	Choose batch when you prefer steady incremental writes.	Ongoing CDC on moderate volumes
Target load	Usually lighter and easier to tune	Heavier during load, but faster overall	Choose batch when the target is already busy or sensitive to large load spikes.	Operational environments with tighter database limits
Snapshot use case	Works well, but slower on very large datasets	Preferred when the target supports it	Choose bulk for initial loads whenever the agent supports snapshot bulk.	Initial snapshot into an empty or reset target

Criterion

Batch mode

Bulk mode

Recommendation

Best fit

Throughput

Good

Highest

Choose bulk when the target can absorb a large ingest window and you want maximum speed.

Large snapshots and other high-volume loads

Latency

Lower setup cost per write, but more round-trips than bulk

Best for large transfers, less efficient for tiny writes

Choose batch when you prefer steady incremental writes.

Ongoing CDC on moderate volumes

Target load

Usually lighter and easier to tune

Heavier during load, but faster overall

Choose batch when the target is already busy or sensitive to large load spikes.

Operational environments with tighter database limits

Snapshot use case

Works well, but slower on very large datasets

Preferred when the target supports it

Choose bulk for initial loads whenever the agent supports snapshot bulk.

Initial snapshot into an empty or reset target

Known constraints

Bulk mode is disabled automatically for PostgreSQL tables that use auto-increment or identity columns.
Not every target agent supports both bulk flags.
Some agents support bulk only for snapshot, some only for CDC, and some for both.
If a target agent does not support a bulk mode, Gluesync falls back to the standard batch path for that entity.

How to configure

Write strategy settings are configured per entity.

maxWriteBatchSize is set on the target agent configuration.
useBulkOperationsWhileSnapshot and useBulkOperationsDuringCDC are set in the entity configuration.

In the UI, open the entity from the Object Browser, then go to Settings and scroll to Optional settings and fine tuning. The Bulk load settings panel contains the bulk checkboxes for snapshot and CDC.

For existing entities, you can change these flags without recreating the entity. Save the configuration and the next run will use the selected write strategy.

The write strategy decides how rows are written, not what happens when the target refuses one. When an insert is rejected because the row is already on the target, the entity’s On duplicate key setting decides whether it is overwritten, skipped, or treated as an error. That setting acts on the batch path: a successful bulk load resolves duplicates with the target’s own load mechanism.

For a broader set of snapshot performance tuning options — including INSERT vs UPSERT strategy, snapshot concurrency, and logical partitioning (all configurable in the "snapshot performances" page under Gluesync Kotlin UI) — see Snapshot Tasks.