Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

2026-09-30T17:17:18.713000Z

Hi Jainish,

This is expected when running PostgreSQL in a cloud provider, such as GCP, AWS, and Azure.
In 3.18 support for these cloud platforms moved to Symmetric-Pro. Please reach out to our sales team to discuss commercial options. https://www.jumpmind.com/symmetricds/trial/

Thank you,
Andy Webb

Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

2026-09-28T08:00:52.385000Z

https://symmetricds.sourceforge.net/doc/3.18/html/user-guide.html#_features

Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

2026-09-28T08:00:07.379000Z

Also, the documentation mentions that Azure PostgreSQL is supported in the Community Edition. In that case, why are we getting this error? Could this be some kind of bug or compatibility issue?

Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

2026-09-28T06:24:01.953000Z

Hello SymmetricDS Support,

We are evaluating SymmetricDS Community Edition 3.18.1 for bidirectional synchronization between an HQ database on Azure Database for PostgreSQL and multiple child sites, each with its own standalone PostgreSQL database.

The child sites are on separate networks. They can connect to HQ over the internet, but we do not have a shared network or VPN. We plan to use GUIDs for row IDs.

When starting the HQ engine against Azure PostgreSQL, we receive:

The detected database platform 'azurepostgres' is not supported in SymmetricDS open source. Azure Database for PostgreSQL requires SymmetricDS Pro.

Could you please confirm:

Is Azure Database for PostgreSQL unsupported as a source and target in Community Edition 3.18.1?
Is there any supported, no-licence-fee SymmetricDS configuration for this bidirectional setup?
If we install SymmetricDS Community Edition on an Azure VM while keeping the database on Azure Database for PostgreSQL, will it connect, or will it still detect azurepostgres and require Pro?

We would also appreciate guidance on synchronization when a child site temporarily loses internet access.

Thank you,
Jainish Patel

BshColumnTransform runs twice for same row - same transform, same key, same values

2026-09-03T05:33:54.986000Z

Hi Pavel,

thank you for your response.

Regarding the two possibilities you mentioned, we have already ruled both of them out:

Duplicate transform setup

Our setup is as simple as it gets:

2 nodes, both Oracle
1 source table, captured by exactly 1 trigger
1 trigger_router entry, routing to exactly 1 target node
1 transform_table entry (LOAD, SOURCE to TARGET)
1 transform_column entry with the BSH script
No other BSH transforms exist anywhere in the configuration

There is no way a duplicate transform is involved here.

Data Conflicts / multiple CDC events from different nodes

We only have 2 nodes in total - one source and one target. There is no multi-master setup, no additional nodes, and no other CDC events being generated. We also confirmed that only one row exists in sym_data for the affected primary key at the time of replication.

So both possibilities you mentioned do not apply to our setup.

The double execution is fully reproducible and consistent - every single UPDATE on the source table results in exactly 2 BSH executions on the target with identical keyValues, dmlType, currentValue and oldValue, approximately 90ms apart.

We will try to reinstall the whole setup from scratch and see if the issue persists. If it does, we will come back here with further findings.

Thanks again.

BshColumnTransform runs twice for same row - same transform, same key, same values

2026-09-02T12:08:06.045000Z

Hi Vincent,
Has the issue been resolved?
Are there any learning to share with the community?
Thanks,
Pavel

BshColumnTransform runs twice for same row - same transform, same key, same values

2026-08-28T13:12:27.658000Z

Hi Vincent,

I can think of two possibilities leading to BSH called twice:

Duplicate transform set up.
Data Conflicts (multiple CDC events from different nodes get reconciled).

Either way the BSH script does not look right. Instead of "context.put" the script should return the NewAndOldValue object:
return new org.jumpmind.symmetric.io.data.transform.NewAndOldValue(newValue, oldValue);

There are some examples floating around with a single value return, but they are outdated and do not apply to versions above 3.12.x

See the "BeanShell Script Transform" section under the 6.15.6 Transform Types in the User Guide https://downloads.jumpmind.com/symmetricds/doc/3.17/html/user-guide.html#_transform_types

If you would like us to take a closer look at the configuration, attach a Support Snapshot here (or email it to support@jumpmind.com).

Here is a link describing how to take a support snapshot:
https://jumpmind.atlassian.net/wiki/spaces/SYMKB/pages/1379860483/Take+a+Support+Snapshot+by+Web+Console

Warm regards,
Pavel

BshColumnTransform runs twice for same row - same transform, same key, same values

2026-08-28T07:28:36.387000Z

Hi,

I have a BSH column transform script that runs twice per row. I have investigated this extensively and cannot find the cause. Here is a full summary of what I found.

Setup:

SymmetricDS Pro 3.17.7 (Trial)
One source table (SOURCE) mapped to one target table (TARGET) via one transform
transform_point: LOAD
update_action: UPD_ROW
delete_action: DEL_ROW
Only one BSH column in sym_transform_column
include_on: ALL (also tested with UPDATE only, same result)
One trigger, one router, one trigger_router entry on the source side
Only one row in sym_data for the affected PK
Tested only with Update-Operation on the source table

Observations:

The script executes twice per row
Both executions have the same transformId, sourceTable, targetTable
Both executions have the same keyValues
Both executions have the same dmlType (UPDATE) and dmlTypeString (UPDATE)
Both executions have the same currentValue and oldValue
Timestamps are approximately 90ms apart
cycleNum (stored in context) increments across both executions, confirming the context is shared between them

Script:

Integer cycleNum = (Integer) context.get("cycleNum");
    if (cycleNum == null) {
        cycleNum = 1;
    } else {
        cycleNum++;
    }
    context.put("cycleNum", cycleNum);
    log.warn("cycleNum: " + cycleNum

        + " | dmlType: " + sourceDmlType
        + " | dmlTypeString: " + sourceDmlTypeString
        + " | transformId: " + transformedData.getTransformation().getTransformId()
        + " | keyValues: " + java.util.Arrays.toString(transformedData.getKeyValues())
        + " | currentValue: " + currentValue 
        + " | oldValue: " + oldValue);

Log output:

2026-08-28 09:18:09,671 WARN [TARGET] [BshColumnTransform] [TARGET-dataloader-4] cycleNum: 1 | dmlType: UPDATE | dmlTypeString: UPDATE | transformId: SOURCE to TARGET (LOAD) | keyValues: [141449] | currentValue: 141449 | oldValue: 141449

2026-08-28 09:18:09,768 WARN [TARGET] [BshColumnTransform] [TARGET-dataloader-4] cycleNum: 2 | dmlType: UPDATE | dmlTypeString: UPDATE | transformId: SOURCE to TARGET (LOAD) | keyValues: [141449] | currentValue: 141449 | oldValue: 141449

Questions:

Is there any known scenario where a LOAD transform with a single BSH column runs twice for the same row with identical values?
Is there an internal SymmetricDS mechanism that could cause this, such as a retry, a conflict check, or a two-phase load?
Is it expected or normal that a BSH LOAD transform runs twice per row under certain configurations?

Thanks in advance.

[Bug] Windows service wrapper JVM runs without -Xms/-Xmx and commits ~1/64 of physical RAM per service

2026-08-12T18:07:09.296000Z

Thanks for reporting this bug. We have added it to our issue tracker. You can use the following link to track its progress:
https://jumpmind.atlassian.net/browse/SYM-7908

[Bug] Windows service wrapper JVM runs without -Xms/-Xmx and commits ~1/64 of physical RAM per service

2026-08-12T16:35:36.775000Z

Product version: 3.14.5 (code verified identical in 3.15 branch)
Component: symmetric-wrapper
OS: Windows Server (issue is specific to Windows commit accounting)

Summary

Each SymmetricDS Windows service runs two java.exe processes: the wrapper
(monitor) and the actual server engine. The heap settings
wrapper.java.initmemory / wrapper.java.maxmemory from sym_service.conf
are applied only to the server process. The wrapper JVM itself is launched
with no -Xms/-Xmx at all, and there is no configuration property that
would allow adding them.

Without -Xms, HotSpot ergonomics set the initial heap to 1/64 of physical
RAM and commit it immediately at startup. On large-memory hosts this makes
every wrapper commit gigabytes of memory it will never use. The committed
pages are never touched, so the working set stays tiny (tens of MB) and the
problem is invisible in Task Manager — but the commit charge counts against
the system commit limit (RAM + pagefile) and silently reduces the headroom
available to other processes. Under load spikes this leads to sporadic memory
allocation failures in unrelated processes, which makes the root cause very
hard to trace.

Environment where observed

Windows Server VM with 170 GB RAM, ~30 GB pagefile (commit limit ~200 GB)
20 SymmetricDS instances installed as Windows services (multi-tenant host)
Each wrapper process committed ~3.1–3.4 GB (initial heap 170/64 ≈ 2.7 GB
JVM overhead), i.e. ~60 GB of commit charge consumed by 20 idle
monitor processes
Working set of all 20 wrappers combined: ~1.1 GB (which is why nothing
looked suspicious in Task Manager)

Root cause (code references)

WrapperService.getWrapperCommand() builds the wrapper command line as:

java -Djava.io.tmpdir=<tmp> -jar symmetric-wrapper.jar <arg> <conf>

with no memory options and no property hook to add any
(symmetric-wrapper/src/main/java/org/jumpmind/symmetric/wrapper/WrapperService.java,
verified on branches 3.14 and 3.15).

WrapperConfig.getCommand() translates wrapper.java.initmemory /
wrapper.java.maxmemory (default 256) into -Xms/-Xmx, but this command
is used only for the spawned server process
(symmetric-wrapper/src/main/java/org/jumpmind/symmetric/wrapper/WrapperConfig.java).

On Windows the service ImagePath runs the wrapper with the init argument,
and Wrapper.main for init calls execJava() in the same process, so the
resident monitor is the unrestricted JVM from the ImagePath.

The issue is effectively Windows-specific: Linux default heuristic
overcommit does not strictly account untouched committed heap, while Windows
requires every committed byte to be backed by RAM + pagefile.

Steps to reproduce

Install SymmetricDS as a Windows service on a host with a large amount
of physical RAM (e.g. 128+ GB).
Start the service.
Inspect the two java.exe processes, e.g.:
Get-CimInstance Win32_Process -Filter "Name='java.exe'" | Select ProcessId, PageFileUsage, CommandLine
Observe: the process running symmetric-wrapper.jar has no -Xms/-Xmx
on its command line and its committed memory (PageFileUsage) is roughly
1/64 of physical RAM, while its working set is only tens of MB.

Measured confirmation

Adding -Xms16m -Xmx64m to the service ImagePath (immediately after the
java executable path) and restarting a single service reduced the system-wide
committed bytes by ~3.4 GB instantly — matching the prediction exactly.
Extrapolated to all 20 services: ~55–60 GB of commit charge recovered.

Workarounds

Insert -Xms16m -Xmx64m into the ImagePath of each SymmetricDS service
in the registry (must be re-applied after sym_service.bat uninstall/install,
which rewrites the ImagePath), or
Set a per-service environment variable
JAVA_TOOL_OPTIONS=-Xms16m -Xmx64m (the server's explicit -Xms/-Xmx
from sym_service.conf take precedence, so the engine is unaffected).

Both are fragile compared to an upstream fix.

Suggested fix

Either:

Hard-code sane defaults (e.g. -Xms16m -Xmx64m) into
WrapperService.getWrapperCommand() — the wrapper only monitors the
child process and reads its stdout, so a small fixed heap is sufficient; or
Introduce configuration properties (e.g. wrapper.monitor.initmemory /
wrapper.monitor.maxmemory) applied to the wrapper JVM in
getWrapperCommand(), with small defaults.

Recent posts to Discussion

Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

Community Edition 3.18.1 and Azure PostgreSQL: supported options for bidirectional sync

BshColumnTransform runs twice for same row - same transform, same key, same values

BshColumnTransform runs twice for same row - same transform, same key, same values

BshColumnTransform runs twice for same row - same transform, same key, same values

BshColumnTransform runs twice for same row - same transform, same key, same values

[Bug] Windows service wrapper JVM runs without -Xms/-Xmx and commits ~1/64 of physical RAM per service

[Bug] Windows service wrapper JVM runs without -Xms/-Xmx and commits ~1/64 of physical RAM per service

Summary

Environment where observed

Root cause (code references)

Steps to reproduce

Measured confirmation

Workarounds

Suggested fix