SymmetricDS: asynchronous database replication for mixed estates

Asynchronous by design, because the network is the constraint

SymmetricDS is described as a Java-based platform for database replication and file synchronization that is platform-independent, web-enabled and database-agnostic, designed to synchronize data across distributed, heterogeneous database environments asynchronously. Every word in that sentence is load-bearing. Asynchronous means a site that is down does not block the other, and the queue of pending changes absorbs the outage. Heterogeneous means the two ends need not be the same database product, which is the case a vendor replication tool cannot serve. Database-agnostic means the connector set determines what is supported, and the repository's own topic tags name a wide spread of engines: relational ones such as db2, derby, oracle, mysql, postgresql, sqlserver, mariadb, hsql, sqlanywhere, sybase and teradata, and non-relational ones such as mongodb, elasticsearch, rabbitmq and snowflake. The description also says it works in near real time across WAN and LAN networks, which is a claim about latency tolerance rather than about being synchronous.

The four problems replication software actually has to solve

The README names the real-world problems this kind of software exists to handle, and the list is more informative than the feature list: conflict resolution, bandwidth constraints, intermittent connectivity and firewalls. Each one breaks the naive design. Conflict resolution is needed because bi-directional replication means both sides write, so somewhere there has to be a rule for what happens when the same row changes in both places. Bandwidth constraints matter because a full row image per change will saturate a link that could have carried only the changed columns, so the synchronisation has to be selective. Intermittent connectivity is the everyday case for a store branch or a remote site, and an asynchronous queue is the structure that handles it. Firewalls matter because the connection has to be established outbound from the site that does not have a public address, and a tool that needs inbound ports is unusable in exactly the environments that need it most.

The module layout tells you how the pieces relate

The repository root shows a multi-module Gradle layout rather than a single project, and the names describe the architecture. symmetric-core holds the shared model, symmetric-client is the piece that runs on each node and captures changes, symmetric-server is the coordinating end that nodes talk to, and symmetric-db is where the database-specific logic sits. Then there are the boundaries: symmetric-io for input and output handling, symmetric-jdbc for JDBC access, symmetric-csv for CSV data sources, symmetric-modules for optional add-ons, symmetric-util for shared utilities, symmetric-wrapper and symmetric-assemble for packaging and distribution. Two directories are less obvious and more revealing. symmetric-sqlexplorer is a SQL explorer, which tells you the platform expects people to inspect the synchronised data directly rather than only through the console. symmetric-stats is a statistics module, which tells you the project treats operational measurement as a first-class concern rather than an afterthought. The default branch is release/3.18, so work happens on a release line rather than on a trunk.

Two editions, and the licence is the dividing line

The open source edition is described as providing the foundation, and SymmetricDS Pro is the professional version built on top of it. The features the Pro edition adds are named: a web user interface for configuration and management, support for clustering, bulk load performance and enhanced security. That list is informative about what the open source edition does not include, and the first item is the significant one, since a web console is usually where the configuration work of a replication platform lives. The README states that Pro is backwards compatible with SymmetricDS, which is what makes trying it against an existing configuration a low-risk exercise. The commercial arrangement is the usual one: Jumpmind sponsors the project and provides professional support, services and software on top of the core. On licensing, the README badge marks the project as AGPL v3 while the repository's licence field carries no standard identifier, so the licence you should read is the AGPL v3 text and the Contributor License Agreement you must sign to contribute code, not a permissive one.

Getting the source and setting up a development environment

The project is developed with Gradle and the developer overview is the entry point. The stated prerequisites are Java JDK 21 or later and the Eclipse IDE, and the environment is created with a Gradle wrapper invocation from the assemble module, which generates Eclipse projects you import into your workspace.

cd symmetric-assemble
./gradlew develop

That step is what produces importable Eclipse projects rather than just a build, so a developer is expected to work inside Eclipse rather than only on the command line. The release artefacts come from a different direction: the README points at a SourceForge download for the packaged distribution and at a Docker Hub repository under the jumpmind organisation, so there is both a traditional installer path and a container path for people who would rather run a service. The community channels are forums on SourceForge, a Discord server, a Stack Overflow tag and a Jumpmind data blog. The release history shows how the project ships: versions 3.18.1, 3.17.9 and 3.16.19 were all published on 2026-09-17, which is a maintenance-branch pattern where several supported lines get a build on the same day, and the last push to the repository was on 2026-10-19.

Where SymmetricDS is the wrong choice

Four situations argue against it. First, if both ends of the replication are the same database product and that vendor already ships replication you trust, a database-agnostic platform is a lot of machinery to re-implement a solved problem. Second, if you need synchronous replication, because the whole design is asynchronous and near real time, and a design where a write must be acknowledged before it counts is a different product. Third, if the two ends share a fast, reliable network and the data volume is small, since the machinery for conflict resolution, bandwidth management and intermittent links earns its cost only when those problems are real. Fourth, if your organisation will not accept AGPL v3 terms, because that licence applies to the open source edition and it is a condition on how you can distribute a modified or networked version. The proprietary Pro edition exists partly because of that, and choosing it changes the cost profile rather than the architecture.

Editorial conclusion

Use SymmetricDS when you have to replicate between database systems that do not share a vendor, where the network between sites is slow or intermittent, and where writes happen on both sides, because the asynchronous design and the conflict handling are the reasons to pick this over a vendor tool. Do not pick it if you want a small, self-contained service, since the module layout, the web management surface and the Pro edition's features make it a platform to plan for. Verify first that a JDBC connector exists for both of your database engines, that the AGPL v3 terms are acceptable for how you intend to use it, and that you can decide which of the two editions you need before you build configuration around the web console, since the Pro features include the interface that the open source edition lacks.

Frequently asked questions

Official sources

1. Issues
2. jumpmindinc/symmetric-ds on GitHub
3. README
4. Releases