Tapdata Community Edition: CDC synchronisation you assemble by dragging

A platform for synchronising data as it changes

Tapdata is described as a Change Data Capture based, real-time data integration platform that enables data to be synchronised in real-time among various systems such as databases, SaaS services, applications and files. The key word is capture. Rather than polling tables on a schedule, the platform follows changes, which is what makes the incremental mode meaningful and what lets a downstream MongoDB or Elasticsearch stay close to its source.

The second half of the product description is about how you build those tasks. Synchronisation tasks can be built through drag-and-drop operations, from table creation to full and incremental synchronisation, and all processes are fully automated. That is the central architectural bet: the pipeline definition is data in a UI, not code in a repository.

The primary use cases listed in the project documentation are concrete. Synchronising data from traditional RDBMS to modern databases such as MongoDB, Elasticsearch or Redis to support new business uses. Consolidating data from various databases into a unified data warehouse. Streaming database changes to Kafka. Performing synchronisation between heterogeneous databases. And using MongoDB to build a unified data hub.

The audience is therefore data platform engineers and database teams who have outgrown hand-written ETL scripts but do not want to operate a heavyweight integration suite. The project is written in Java, published under Apache-2.0, and the repository is not archived, with the last push on 2026-10-20.

Community, Cloud and Enterprise are three products in one repository

Tapdata ships in three distribution versions: Community Edition, Cloud Service and Enterprise Edition. The project documentation states plainly that all content under the open source repository corresponds to the Community Edition, and that the differences between the three are described on the vendor site.

That distinction is the first question to ask. The open source repository is not a cut-down SDK, it is one of three editions, and the functionality split between editions is not documented in the repository itself. A team that needs a specific connector or a specific deployment mode may find that it lands in Cloud or Enterprise, in which case the self-hosted path does not apply.

The repository layout does show the shape of the platform. There are manager/ and iengine/ directories for the two main server components, common/ for shared code, odh/ for the developer hub, openapi-generator/ for the generated API surface, tapdata-cli/ for a command line client, tapshell/ for a shell component, and directories for tests (auto-test/, tapdata-test/), build and release scripts, plus docker-compose.yml and docker-compose.local.yml alongside a Dockerfile.

The presence of a Maven pom.xml at the root and a package.json with commitizen configuration for conventional changelog commits tells you the build is Maven based with a JavaScript toolchain layered on for release discipline. There is also an OAuth2_JSON_Support.md document and an .env file at the root, which points to configuration being part of the deployment story rather than an afterthought.

The ETL layer is a set of visual processors

The lightweight ETL solution is described through three processor groups, and it is where a lot of the practical value sits if your databases do not have matching schemas.

Table filter and mapping gives you rich visual processors for table selection, renaming, adding or deleting fields, and renaming. That covers the most common reason a replication task fails to start: the source and target do not have the same columns. Rather than writing a transformation script, you select and rename in a UI.

Record transformation lets you use JS or Python code to do the transformation, and this is the escape hatch. The two languages cover the two common profiles of a data engineer: JavaScript for people who live in the Node and browser ecosystems, Python for people who live in the data and science ones. Writing code inside a task definition is not as adjustable as a versioned script, but it is enough for the class of transformation where a value needs a computed rewrite rather than a rename.

Union joins multiple tables into one target, which is the third building block. Combined with the two above, a task can merge several sources, reshape them and land them in a single target, which is the shape most consolidation and warehouse loading work takes.

The monitor capability completes the loop. The documentation describes monitoring sync performance, task progress, key events and logs, which is what turns a platform into something you can operate rather than merely configure.

Materialized views in MongoDB, including multi-table stream merging

The MongoDB materialised view feature is the most distinctive part of the open source edition, and it is aimed squarely at teams moving off relational databases.

Document-style view supports embedded documents and arrays, deeply integrated with MongoDB, which is what lets a flat relational row become a nested document rather than a string of columns. Multi-table association covers hierarchical nesting and the construction of one to one and one to many models, so relational joins become document structure.

The hardest-sounding feature is multi-table stream merging, described as unified batch and stream processing with multi-table updates in any order. That last clause is the important one. When two source tables both feed one MongoDB document, updates can arrive in either sequence, and a view that only handles them in order will produce wrong documents. Handling updates in any order is what makes the merged view usable against live data rather than only against a consistent snapshot.

Combined with the use case of building a unified data hub on MongoDB, this is where the CDC model pays off. A document that aggregates several tables has to be recomputed whenever any of them changes, and change capture gives the platform the trigger it needs.

The caveat is that these views are described in the feature list rather than in a specification. The documentation for the supported connectors lives at docs.tapdata.io, and the repository itself does not explain the semantics of the view engine in enough detail to design against without reading it.

Running the whole service from one container image

The quick start is a single container run, and the project states the resource requirements up front: at least 5GB of available memory, at least 20GB of available disk space, and at least one free CPU core. The image is published on GitHub Container Registry as ghcr.io/tapdata/tapdata:latest, and the documentation says to wait three minutes after starting it before opening the web interface on port 3030, where a login page appears if everything came up.

For anything beyond a trial, the compose file in the repository root is the better starting point, because it shows the real topology. The mongo service runs the same image and starts a mongod with a replica set named rs0, which is what a change data capture engine needs in order to read the operation log:

  mongo:
    image: ghcr.io/tapdata/tapdata:latest
    container_name: tapdata-mongo-official
    hostname: tapdata-mongo-official

The tm service runs the task manager jar against that MongoDB instance, and the port mapping exposes it:

    ports:
      - "${WEB_PORT:-3030}:3000"

Note the port discrepancy, which is not a mistake. The container listens on 3000 and the host publishes 3030 by default, with the value overridable through the WEB_PORT environment variable, and MONGO_PORT does the same for the database port.

Building from source uses a multi-stage Dockerfile, and the connector set is a build argument, so you can build a smaller image with only the connectors you need:

FROM maven:3.8-openjdk-17 AS builder
ARG TAP_CONNECTORS="mongodb"

The build stage is a Maven image on OpenJDK 17, and the first stage keeps only the pom.xml files so dependency layers cache across source changes. Building from source is documented separately in building.md, and the Makefile targets and scripts/ directory hold the rest of the build and release automation.

Where the release line and the commit line have diverged

The maintenance picture needs care, and this is the part that decides whether you pin a version or track the branch.

The repository is not archived and the last push was on 2026-10-20, so work is clearly continuing. The tagged releases, however, tell a different story: v3.25.0 on 2025-03-19, v3.26.0 on 2025-04-14 and v3.27.0 on 2025-04-14, two of them on the same day. There is no tagged release after April 2025 in the list, even though the branch has been receiving commits for a year and a half since.

That gap has two possible readings, and the repository does not settle which applies. Either releases are tagged less often than the code changes, or the tagged line and the main branch have diverged. In practice, an evaluator has to build from main and compare against the published image rather than assume the tag describes the current state.

The licence is Apache-2.0 with the LICENSE file at the root, which is a permissive licence with an explicit patent grant and no commercial condition attached to the Community Edition. That part of the adoption decision is simple, and it is the distribution split that deserves attention: the code is Apache-2.0, but which edition you can run against which connector is a product question, and the answers live on the vendor site rather than in the repository.

The repository also carries a RELEASE directory and a changes/ directory, which is where you would look for the detail behind a version difference.

Editorial conclusion

Adopt Tapdata Community Edition if you need change data capture between heterogeneous databases, want table creation, incremental sync and ETL defined visually rather than in code, and can operate a Java platform that wants 5GB of memory and 20GB of disk. Do not adopt it if you need a lightweight connector, if you cannot run a MongoDB dependency, or if you need a release train you can pin to, since the newest tagged release is v3.27.0 from 2025-04-14 even though the repository was pushed to on 2026-10-20. Before you commit, build the Docker image from source and compare it with the published image, check that your source databases appear in the supported connectors list at docs.tapdata.io, and confirm which of the three editions, Community, Cloud or Enterprise, contains the connector you actually need.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tapdata/tapdata on GitHub