Syncle

Syncle is a self-hosted tool for replicating data between databases that don't share an engine. Postgres to MySQL, MongoDB to Postgres, Redis to an HTTP endpoint, any combination of PostgreSQL, MySQL, SQLite, MongoDB, and Redis, plus webhook-style delivery to HTTP. The problem it's built against is that the standard answer to heterogeneous replication is a Kafka cluster, a change capture connector, a connector marketplace, and a schema registry, which is a platform to operate before you've synced a single row. Syncle is four containers behind one port, and bridges are created in a web interface and watched from a live delivery timeline.

The unit of work is a bridge, a source plus one or more destinations. Each bridge runs in one of three modes. Replay does a one-time backfill of all rows or a filtered subset. Watch polls the source on a cursor, an auto-increment ID, an updated_at timestamp, or a primary-key diff, and is the option for sources that can't emit changes. CDC reads the engine's own change log, logical replication on Postgres, the binlog on MySQL, change streams on MongoDB, and keyspace notifications on Redis, for near-real-time flow with delete propagation. Writes on the destination side are idempotent upserts, so a replayed batch never creates duplicates, and a bridge that's interrupted picks up from its checkpoint rather than starting over. A bridge can fan out to several destinations, so one Postgres source can feed a MySQL replica and a webhook at the same time.

Around the core there's a fair amount of operational convenience. Destination tables are created automatically with type translation across engines, columns can be mapped and renamed for the common case where the destination schema differs slightly, HTTP destinations take a JSON payload template and POST, PUT, or PATCH delivery so the receiving service gets exactly the shape it expects, and a live delivery timeline shows each record with retry, skip, and resume controls. Remote databases can be reached over SSH tunnels, and a built-in workbench lets you browse tables, run queries, and manage schemas without opening a separate client. The site has a video of a bridge being created end to end, which is a fair way to judge how much clicking is involved.

Deployment is a curl install script that brings the stack up, or a docker compose file with a master key you generate with openssl. The four services are a NestJS API, a Next.js web interface, a PostgreSQL metadata store, and Redis running the BullMQ job queue, published behind a single port. No Kafka, no external scheduler, no connector marketplace. Building from source needs Node 22 and pnpm 10.

It's for individual operators and small teams who run their own infrastructure and want data to land in a second system without adopting a streaming platform. The typical shapes are a legacy app that still reads MySQL while the new one writes Postgres, a reporting database fed from a MongoDB application store, or row changes pushed to a webhook so another service can react. Version 1.3.0 shipped on 8 September 2026 with a changelog and releases page, and the project is MIT licensed with a modest but active GitHub presence and discussions for setup help.

Where it differs from the streaming stacks is that it's a single self-contained application with a UI, not a set of components to wire together. That's also the honest boundary. It's not built for the throughput or the guarantees a Kafka pipeline gives a large organisation; it's built so one person can stand up a reliable sync in an afternoon. The limits are documented rather than hidden. MariaDB CDC is untested, though MySQL CDC is verified. Redis CDC isn't durable, so changes made while a bridge is offline are lost. SQLite has no change log, so watch bridges are the option there. And the stack is designed for local or trusted-network use, with TLS expected before you expose it more widely. It's also young, so the operational track record is short.

Access is free and open source. There's no hosted plan or paid tier; you run it yourself. For anyone comparing it with a hosted ELT service, the difference is that nothing leaves your network; the sources, the destinations, and Syncle itself all run where you put them. Nine documentation pages cover installation through troubleshooting, questions go to GitHub Discussions, and security reports have a dedicated address on the self-hosting page. There's no general contact email.