Question 1

Which databases can Syncle sync between?

Accepted Answer

PostgreSQL, MySQL, SQLite, MongoDB and Redis — in any combination. A relational source can write into a document or key-value store and back, with values translated to fit the target. HTTP endpoints work as a destination too, when you are feeding a service rather than a database.

Question 2

Does it sync in real time, or on a schedule?

Accepted Answer

You choose per bridge. CDC reads the database change log directly — Postgres logical replication, MySQL binlog, MongoDB change streams, Redis keyspace notifications — so changes arrive without polling. Watch polls a cursor instead, which works on every engine, including SQLite, which has no change log to read. The cursor can be an auto-increment id, a timestamp column, or a diff of the primary keys — so a table with no updated_at column can still be watched. Replay is a one-shot pass for the initial backfill.

Question 3

Can it duplicate or lose rows?

Accepted Answer

Writes are idempotent upserts keyed by the columns you pick, so a replay, a retry or a redelivery rewrites the same row rather than adding another. Jobs record their cursor as they go, so an interrupted run resumes where it stopped instead of starting over. What each trigger sees differs: a CDC bridge propagates inserts, updates and deletes; a watch bridge polls, so it sees new rows (and updates, on a timestamp cursor) but never deletes. And Redis CDC rides keyspace notifications, which are not durable — if Syncle is down when a Redis key changes, that event is gone.

Question 4

What do I need installed to run it?

Accepted Answer

Docker with Compose v2, and curl for the installer — that is what the install script actually checks before it will run. Node, PostgreSQL and Redis all run in containers, and the application image is pulled prebuilt, so nothing is compiled on your machine.

Question 5

Is Syncle free, and is my data sent anywhere?

Accepted Answer

It is MIT licensed and entirely self-hosted. It runs on your own machine against your own databases; there is no account and no third-party service in the data path. Stored connection credentials are encrypted with AES-256-GCM under a key that never leaves your install.

Question 6

How is it different from Airbyte or Debezium?

Accepted Answer

Scale of setup. Airbyte expects a platform deployment — Kubernetes, or Docker Compose at smaller scale — and a team to operate it; Debezium expects Kafka. Syncle is one command, four containers and a web interface, aimed at one operator who wants their databases kept in step without standing up a data platform first.

Question 7

How much can it move?

Accepted Answer

A million rows, cross-engine, in well under a minute on a laptop — every one arriving exactly once. Rather than quote a figure here that goes stale the moment the code moves, the measured results live on the benchmarks page, together with the machine they were taken on and the runner that produced them. The shape worth remembering: round trips, not the database, set the pace, which is why work is sent in batches rather than a row at a time. There is no published benchmark against a managed or remote database yet, and latency dominates there.

Question 8

What happens if the destination goes down?

Accepted Answer

By default the reader stops advancing, which means the source keeps its change log until the destination is back — safe, but on PostgreSQL a long outage leaves WAL accumulating on the source. Turning on the optional spool changes that: changes are written to a durable Redis stream first and the source is acknowledged immediately, so its log advances at the speed of Redis rather than the destination. The spool is bounded, so a stalled destination throttles the reader instead of growing without limit. It is off by default, because while a change sits in the spool Redis is the only copy of it and that trade should be deliberate.

Scenario	Rows	Time	Rows / sec
PostgreSQL → PostgreSQL · batched verified: 1000000 rows, exactly once syncle cpu (peak / avg): 221% / 26% syncle memory (peak): 249 MB pg cpu / memory (peak): 176% / 1335 MB	1,000,000	15.9 s	62,743
PostgreSQL → MySQL · batched verified: 1000000 rows, exactly once syncle cpu (peak / avg): 205% / 46% syncle memory (peak): 287 MB pg cpu / memory (peak): 88% / 1420 MB mysql cpu / memory (peak): 53% / 1760 MB	1,000,000	11.1 s	89,847
MySQL → PostgreSQL · batched verified: 1000000 rows, exactly once syncle cpu (peak / avg): 224% / 29% syncle memory (peak): 369 MB pg cpu / memory (peak): 127% / 1609 MB mysql cpu / memory (peak): 82% / 1838 MB	1,000,000	11.4 s	87,789
PostgreSQL → MongoDB · batched verified: 1000000 rows, exactly once syncle cpu (peak / avg): 258% / 10% syncle memory (peak): 288 MB pg cpu / memory (peak): 105% / 1820 MB	1,000,000	46.9 s	21,325
PostgreSQL → PostgreSQL · batched + durable spool verified: 1000000 rows, exactly once syncle cpu (peak / avg): 266% / 51% syncle memory (peak): 527 MB pg cpu / memory (peak): 138% / 1616 MB peak spool depth: 83789	1,000,000	21.1 s	47,375

Scenario	Rows	Time	Rows / sec
PostgreSQL · upsert syncle cpu (peak / avg): 86% / 8% syncle memory (peak): 130 MB pg cpu / memory (peak): 98% / 1227 MB	1,000,000	8.50 s	117,606
MySQL · upsert syncle cpu (peak / avg): 82% / 22% syncle memory (peak): 176 MB mysql cpu / memory (peak): 110% / 1811 MB	1,000,000	3.62 s	276,091

Benchmarks

Read this before quoting a number

The configuration

The machine

Change data capture, end to end

Destination write ceiling

Reproducing this