Comparison · checked July 2026
durable-sync vs the real sync engines
Most of the time, one of the others is the right answer. This page is about the times it isn't.
The axis that actually decides it
What does it need running?
Feature checklists move every quarter. The structural question doesn't: every engine below except this one and partysync needs a database and a long-running process to sit in front of it. If you are already paying for Postgres, that cost is zero and you should use one of them — they are better than this at almost everything. If you are all-Cloudflare, it means standing up a second backend and keeping it alive forever.
| Engine | Needs running | Offline writes | Conflict resolution | Live push |
|---|---|---|---|---|
| durable-sync | A Durable Object. Nothing else. | Yes — durable outbox | None, deliberately | No — converges on foreground |
| partysync | A Durable Object. Nothing else. | No write queue — read cache only | Delta sync; the DO serializes writes | Yes — WebSocket |
| Zero | Postgres + zero-cache | No — an explicit non-goal | Server-authoritative mutators | Yes |
| Electric | Postgres + Electric service | Read-path sync; writes are yours | Yours to define | Yes |
| PowerSync | Postgres/Mongo/MySQL/MSSQL + service | Yes — first-class | Backend-delegated; last-write-wins default | Yes |
| Triplit (unmaintained) | Its own server (had a DO adapter) | Yes | Yes | Yes |
| Yjs / Automerge | A transport you pick | Yes | Real CRDT merge | Depends on provider |
Checked against primary docs, July 2026. These projects move fast and this table is written by someone with an obvious interest — if a row is wrong or out of date, open an issue and it gets fixed. Neither "conflict resolution" nor "offline writes" is one capability: PowerSync queues writes and hands them to your backend to arbitrate, Zero reconciles on an authoritative server, and a CRDT merges without one. A column can only ever be a pointer to the real docs.
Straight answers
Which one should you use?
Use PowerSync, Zero or Electric if…
You already run Postgres, or you'd accept running it. You need real conflict resolution, partial sync of a large dataset, or instant cross-device updates. They are mature, staffed, and genuinely better engineered for the general case. This library does not compete with them and isn't trying to.
One caveat on that list: Zero rejects writes while disconnected and describes itself as "not local-first," so if offline is the requirement it's out regardless of what you're willing to run. And PowerSync — the one that does offline properly — resolves conflicts by handing the write queue to your backend, defaulting to last-write-wins. Which is the same shape as the answer here, with a Postgres and a service under it.
Use Yjs or Automerge if…
Two people can edit the same thing at the same time and you need the result to merge rather than for one of them to win. That's a CRDT problem, and reaching for anything else is a mistake you'll pay for later.
Use partysync if…
You're all-Cloudflare, you want live updates over a WebSocket, and your users are never offline. It's Cloudflare's own, and it's the better fit whenever offline genuinely doesn't matter.
Use durable-sync if…
You're all-Cloudflare and unwilling to add a second backend, your writes are events rather than edits — "this set happened", "this expense was recorded" — and the app has to keep working on a train. That's a narrow slice. Inside it, a Durable Object already gives you a single-threaded ordering point per user, which is the exact thing the others need Postgres for, and the remaining work is an outbox and a cursor. That's this package.
The catch
What you give up
A pull returns everything after your cursor in one response — fine for thousands of ops, not for millions. There's no live push, so the other device learns about a write on its next foreground. There's no auth. And nothing runs while the app is closed, because Safari has no Background Sync and pretending otherwise would be a lie.