SymmetricDS 3.18: Built to Run Anywhere You Run Containers

We built 3.18 because the question we kept hearing from customers changed. It used to be “can SymmetricDS sync my data correctly?” Now it’s “can SymmetricDS run natively in my Kubernetes cluster, and can I see what it’s doing once it’s there?” 3.18 is our answer to both.

SymmetricDS now runs like a cloud-native service, not a service you bolted onto a container

If you’ve deployed SymmetricDS in Docker or Kubernetes before, you know the friction. Missing health probes to wire into your orchestrator, configuration that requires a properties file instead of environment variables. There are now Liveness and Readiness endpoint APIs your orchestrator can probe directly. JVM settings, server config, and endpoint or startup parameters can all be imported from environment variables instead of mounted files. The container image runs under a minimum-privilege account instead of a broader default. Underneath, we switched the default database connection pool to HikariCP and moved logging from Log4j2 to Logback. Both changes happen automatically on upgrade. If you had a custom db.pool.type, we preserve it rather than silently overriding your setting.

A real Analytics tab, not just logs to grep through

We added an entire Analytics section to the console: a Capture Health screen sourced from sym_trigger_hist, a Cluster Traffic view, and heat maps for table data changes and node backlogs, filterable by metric and event type. There’s also a REST API endpoint if you want to pull analytics data into your own dashboards, and report timestamps now respect a configurable time zone instead of assuming the server’s.
We’re not going to oversell this as a full observability platform — it’s not Grafana. What it is: the first place you should look when someone asks “is node 47 actually keeping up,” and you no longer have to reconstruct the answer from sym_data row counts.

Table Heat Maps

Capture Health

Backlog By Connection (Node)

Cluster Traffic

Data Refresh grew up

Data Refresh used to be one job, one behavior. In 3.18 it’s a set of configurable behaviors. You can now run multiple Data Refresh jobs with different table assignments instead of one global job. Truncate-based and delete-based refresh are distinct job types instead of one mode wearing two hats. The Deploy Wizard can assign a Data Refresh job to tables that aren’t eligible for CDC, closing a gap where those tables previously had no good sync story. This release now supports the ability to replicate directly from database views, not just tables.

File sync gets its own place on the canvas

File sync used to mean a separate setup path — different screens, a different mental model than database replication. In 3.18, it’s the same canvas. Add an endpoint on the Configure Diagram and pick a type — Filesystem, File Sync S3, MinIO, Azure Blob, SFTP, or Google Drive are all options alongside your databases — enter the bucket or base directory and credentials, then draw the connection to another endpoint exactly like you’d wire two databases together.
Each connection gets its own File Capture configuration: source and target directories, include/exclude file patterns, an option to recurse subdirectories, and separate triggers for sync on create, sync on modified, and sync on delete. Conflict strategy (for example, source wins) and auto-reload are set per connection, and because each direction of a link configures independently, a two-way filesystem sync can run different rules each way. From there it deploys through the same Deploy Wizard as every other endpoint — permissions check, runtime database assignment, the works.
The point isn’t that file sync got a facelift. It’s that it stopped being a separate feature you had to learn and became another endpoint type on the diagram you already use.

Broader reach, a few pieces at a time

Generated and computed columns are a real headache in cross-database replication, and we’re closing that gap platform by platform. Oracle’s MATERIALIZED computed columns and SQL Server’s RETAINED computed columns are supported starting in 3.18. MariaDB, MySQL, and PostgreSQL generated-column support is in progress and not ready yet — we’ll cover those in a follow-up release rather than ship them half-tested.
Elsewhere: MinIO joined our supported object storage targets, Amazon SQS is now a supported load-only endpoint, and we split out a File Sync-only endpoint for deployments that need file replication without full data sync. Column transforms also picked up variable substitution for isBlank, isEmpty, and isNull, and the Column Match router now supports $() variable syntax.

The unglamorous stuff that still matters

We upgraded Spring Boot to 4.1.0, Spring Security to 7.1.1, and Bouncy Castle to 1.84, and worked through a SonarCloud security and maintainability pass. None of that shows up in a feature list, but if you’re running SymmetricDS in a regulated environment, your security team will care more about this paragraph than the analytics screens.

Get 3.18

Download SymmetricDS 3.18, or grab it through your existing Jumpmind support channel. For the upgrade path — including steps for clustered installations — see the Upgrading section of the User Guide.
We’re not finished with generated columns on MariaDB, MySQL, and PostgreSQL. If that’s blocking your migration, tell us — it’ll help us prioritize which platform we finish first.