Both use local SQLite and keep the backend authoritative. The main difference is that PowerSync mostly handles downstream replication and gives you an upload queue; your API still owns the write semantics. Syncular specifies the whole round trip. Durable commits, auth scopes, conflicts, replay, revocation and bootstrap.
Syncular also goes further up the stack: schemas plus SQL/SYQL generate typed queries for TS, Swift, Kotlin, Dart and Rust, and blobs, CRDT/encrypted columns and windowed sync are built into the protocol.
In my separate benchmark harness, Syncular currently does considerably better than the tested PowerSync setup. For example, 100k bootstrap is ~0.57s vs ~6.5s and offline replay ~35ms vs ~5.1s. Those are early results from one environment, though, not a universal claim (https://github.com/bkniffler/offline-sync-bench).
I've used PowerSync in the past with a huge initial bootstrap sync and was very frustrated by the performance back then (ca 1 year ago), which was one of the reasons to create my own library.
PowerSync is much more mature today obviously and still a great and proven tool.
Firstly, it's awesome that you are using @sqlite.org/sqlite-wasm for your client-side SQLite database. We really like wa-sqlite ourselves.
We're currently implementing this proposal https://github.com/orgs/powersync-ja/discussions/376, which will speedup the sync throughput a lot - this was a natural next step for us as we have users with massive datasets (syncing a million plus rows).
Sidebar: What has your experience with OPFS+SQLite been like on sqlite-wasm? We have seen our fair share of issues on Safari/web kit.
Hey, nice, looks like I’ll have to rerun the benchmarks soon!
sqlite-wasm with opfs-sahpool has mostly behaved. No OPFS in private mode, storage may be evicted, handles can’t be passed to workers, and webviews may close them when backgrounded.
We open SQLite inside one dedicated worker and proxy other tabs through it, so that avoids some of the mess. Tauri uses native SQLite.
Both use local SQLite and keep the backend authoritative. The main difference is that PowerSync mostly handles downstream replication and gives you an upload queue; your API still owns the write semantics. Syncular specifies the whole round trip. Durable commits, auth scopes, conflicts, replay, revocation and bootstrap. Syncular also goes further up the stack: schemas plus SQL/SYQL generate typed queries for TS, Swift, Kotlin, Dart and Rust, and blobs, CRDT/encrypted columns and windowed sync are built into the protocol.
In my separate benchmark harness, Syncular currently does considerably better than the tested PowerSync setup. For example, 100k bootstrap is ~0.57s vs ~6.5s and offline replay ~35ms vs ~5.1s. Those are early results from one environment, though, not a universal claim (https://github.com/bkniffler/offline-sync-bench).
I've used PowerSync in the past with a huge initial bootstrap sync and was very frustrated by the performance back then (ca 1 year ago), which was one of the reasons to create my own library.
PowerSync is much more mature today obviously and still a great and proven tool.
Hey PowerSyncer here :)
Firstly, it's awesome that you are using @sqlite.org/sqlite-wasm for your client-side SQLite database. We really like wa-sqlite ourselves.
We're currently implementing this proposal https://github.com/orgs/powersync-ja/discussions/376, which will speedup the sync throughput a lot - this was a natural next step for us as we have users with massive datasets (syncing a million plus rows).
Sidebar: What has your experience with OPFS+SQLite been like on sqlite-wasm? We have seen our fair share of issues on Safari/web kit.
Hey, nice, looks like I’ll have to rerun the benchmarks soon!
sqlite-wasm with opfs-sahpool has mostly behaved. No OPFS in private mode, storage may be evicted, handles can’t be passed to workers, and webviews may close them when backgrounded.
We open SQLite inside one dedicated worker and proxy other tabs through it, so that avoids some of the mess. Tauri uses native SQLite.