DBSyncer: a Java data sync middleware with a web console and plugins

The connector table is the product

DBSyncer is a data synchronisation middleware written in Java, and the list of what it can connect to is the clearest statement of its scope. The table marks each connector for use as a source, as a target, or both, and gives a supported version range. MySQL from 5.7.19 upward, Oracle from 10g to 19c, PostgreSQL from 9.5.25, SQL Server from 2008, and the domestic Chinese engines including Dameng DM8, Kingbase V8, OceanBase, Doris, StarRocks and TiDB. Outside the relational world there is Elasticsearch from 6.0.0 to 8.15.3, MongoDB from 4.2, Kafka from 2.10, Redis, RocketMQ from 4.9.x, ClickHouse from 22.x, DuckDB, H2, SQLite and plain files in txt and unl format, plus HTTP and a generic SQL source. Almost all of these work in both directions, which is what makes the tool useful for the common case of moving data out of a production database and into a search index or a warehouse.

Full and incremental sync, with the difference spelled out for Redis

The design has two modes of operation. A full sync loads the existing data, and an incremental sync follows changes as they happen, and the console shows statistics for both. The connector table makes the distinction visible in one place: for Redis the row separates the two roles, listing it as a source for incremental CDC across 5.x to 7.x, and as a target from 2.6 upward. That distinction, a change data capture source versus a plain write target, is the kind of detail that decides whether a connector is usable for your case. The project also lists a generic SQL connector that works with the relational databases above it, as a source only, which is the escape hatch for a query you want to drive the sync from rather than a table listing. The other two stated characteristics of the tool are a combination-driven model, where you pair a driver with a table and a mapping between them, and real-time monitoring of the running state, results, sync logs and system logs.

Uploading a plugin is how you change the transformation

The third stated feature is plugin development, described as customising the conversion and synchronisation logic, and the runtime container confirms the design. The repository is split into modules with a clear division of labour: dbsyncer-connector holds the connectors, dbsyncer-parser and dbsyncer-storage handle parsing and persistence, dbsyncer-plugin is the extension point, dbsyncer-biz and dbsyncer-manager hold the business logic and the scheduling, dbsyncer-sdk is the integration surface for other components, and dbsyncer-web is the console. The Docker run command mounts a plugins directory from the host into the container at /app/dbsyncer/plugins, alongside the data and logs directories, so a plugin jar is dropped in from outside the image rather than baked into it. The stated purpose of the plugin mechanism is uploading a plugin to define your own conversion business logic, which in practice is how you handle a field mapping that neither a plain table copy nor a SQL source can express.

Running the community edition locally

The install path assumes a Java runtime, not a build toolchain. The prerequisites call for JDK 1.8, and the community edition is distributed as a zip package, dbsyncer-x.x.x.zip, with a separate professional edition package named dbsyncer-enterprise-x.x.x.zip. After unzipping you start it with the script for your platform, bin/startup.bat on Windows or bin/startup.sh on Linux, then open a browser at the local port:

http://127.0.0.1:18686

The console logs you in with the account and password admin and admin, and that default is worth changing before the instance is reachable by anything other than your own machine. The professional edition has its own install guide in the project wiki, and the community edition guide is separate, so the two editions are not interchangeable packages. Building from source is also documented, and it assumes you already have JDK and Maven installed:

$ git clone https://gitee.com/ghi/dbsyncer.git
$ cd dbsyncer
$ chmod u+x build.sh
$ ./build.sh

The project is mirrored on both Gitee and GitHub, and the clone command in the documentation points at the Gitee address.

The Docker image and the volumes it expects

The Docker route pulls from a private registry rather than Docker Hub, and there are separate images for the two editions. Both a latest tag and a pinned 2.1.5 tag are published:

docker pull images.dbsyncer.cn/xhtb-dbs/dbsyncer:latest
docker pull images.dbsyncer.cn/xhtb-dbs/dbsyncer:2.1.5

The run command is where the operational decisions sit, and every one of them is explicit:

docker run -d \
  --name=dbsyncer \
  --restart=unless-stopped \
  -p 18686:18686 \
  -e TZ="Asia/Shanghai" \
  -m 5g \
  --memory-swap=5g \
  -v /opt/dbsyncer/data:/app/dbsyncer/data \
  -v /opt/dbsyncer/logs:/app/dbsyncer/logs \
  -v /opt/dbsyncer/plugins:/app/dbsyncer/plugins \
  --log-driver json-file \
  --log-opt max-size=100m \
  --log-opt max-file=7 \
  images.dbsyncer.cn/xhtb-dbs/dbsyncer:latest

The port mapping is the same 18686 you browse locally. The three volumes are the state directory, the log directory and the plugins directory, all under /opt/dbsyncer on the host. The memory limit is 5g with the swap limit matched to it, which tells you the process is expected to be memory hungry. The log driver is the json-file driver with a 100m cap and seven files kept, so the container does not fill the disk.

The everyday commands for a running instance are also listed: tailing the container logs with docker logs, following them live, opening a shell inside the container with docker exec, and the stop, start, restart and remove cycle, with the note that removal requires the container to be stopped first.

Published throughput numbers, with the caveat they carry

The project publishes a performance section, which is unusual and useful, and it separates full sync from incremental. For a full sync of 100 million records, the table reports 31 minutes 50 seconds on a Mac with an Apple M3 Pro, 12 cores and 18GB of memory, 37 minutes 52 seconds on Linux with an Intel Xeon E5-2696 v3B, 8 cores and 48GB, and 57 minutes 43 seconds on Windows with an AMD Ryzen 7 5800x, 8 cores and 12GB. For incremental sync with 4GB of allocated memory the same three machines are listed at 8112 transactions per second with a peak of 11000, 8000 with a peak of 10000, and 7553 with a peak of 9000. These are the vendor's own figures, measured on their own data and hardware, and the incremental numbers in particular depend on the shape of the changes and on which connector is on each side. Read them as an order of magnitude for a Java process doing change data capture, not as a promise for your workload.

The FAQ lists the failure modes you will hit

The common problems section is short and unusually concrete. MySQL that will not connect usually means a driver version mismatch: the default driver shipped is 8.0.21, and for a MySQL 5.x server you have to replace it manually with the 5.1.40 driver, which is attached in the project repository. A SQL Server that will not connect is often a TLS negotiation failure, with the linked case describing a server that selects protocol version TLS10 while the client only accepts TLS12. Data that arrives as garbled text after a move from MySQL 8 into SQL Server 2008R2 points at character encoding on the nvarchar columns, and there is a linked issue for that case as well. Remote debugging has its own issue thread, which is worth finding before you need it, since the default configuration is not set up for it. None of these are deep design flaws, they are the ordinary friction of moving data between systems with different defaults, and having them written down saves an afternoon each.

Two editions, an open source core and a commercial path

The project describes itself as open source data synchronisation middleware, and the licence field on the repository says Apache-2.0 with the LICENSE file at the root. The two editions are the point to understand before you plan a deployment. The community edition is the zip package and the dbsyncer image, and the professional edition is a separate package, a separate image and a separate installation guide, with the professional edition description kept in the project wiki. The stated goal of the team is to keep the project open source so that every user can complete a data sync, and the support routes listed are a QQ group, a Gitee issue tracker and a pull request queue, with internal referrals and commercial cooperation offered as a separate route. The main repository has no GitHub releases, so the distribution mechanism is the release pages on Gitee rather than a tag history, and the last push was on 2026-10-19. The Java build uses Maven with a pom.xml at the root, and there are both build.sh and build.cmd scripts alongside install.sh and install.cmd, so the same source is expected to be built on more than one platform.

Editorial conclusion

DBSyncer suits a team that needs to move data between a relational database and a search engine, a message queue or another database, and that wants to see sync volume, lag and errors in a browser console rather than in log files. It does not suit a team that needs a managed service, since the project distributes zip packages and Docker images and expects you to operate it yourself. Before adopting it, change the default admin credentials on the admin/admin login, pick the edition that matches the connectors you need, and check the driver version note for MySQL 5.x, because the bundled default is 8.0.21.

Frequently asked questions

Official sources

1. 86dbs/dbsyncer on GitHub
2. Issues
3. License: Apache-2.0
4. README