Performance regression in desktop integration tests after upgrading 1.18.0 to 2.0.1

[xvrh]

We have an integration test suite running on macOS that previously completed in under 10 seconds with version 1.18.0. After upgrading to 2.0.1, the same suite now takes over a minute to run.

I haven't pinpointed the exact cause yet, but it appears synchronization is noticeably slower. Happy to dig deeper and share more details if that would help narrow it down.

On a positive note: in the previous version we had to download libpowersync.dylib manually and wire it up with a custom factory. That's no longer necessary in 2.0.1 ❤️.

[simolus3]

Thanks for the report! We haven't seen any notable performance regressions in our sqlite_async benchmarks, so more information to might help us track this down would definitely be helpul! E.g. if you have a somewhat isolated test you could share that was slowed down, we would love to take a look at that.

[xvrh]

Small update with timings from our suite (integration tests against a local PowerSync service, running the Dart client on macOS):

Each test follows the same pattern: open a fresh PowerSyncDatabase, subscribe to some streams and wait for server-side changes to become visible locally.

00:01 +0: Environment syncs after creation                                                                                                                                               
[PowerSync] INFO: 2026-04-23 13:30:17.490898: Starting Rust sync iteration
[PowerSync] FINE: 2026-04-23 13:30:17.501199: Credentials: PowerSyncCredentials<endpoint: http://localhost:8051 userId: null expiresAt: null>
[PowerSync] INFO: 2026-04-23 13:30:17.508679: Ending Rust sync iteration. Immediate restart: false
[PowerSync] INFO: 2026-04-23 13:30:22.510947: Starting Rust sync iteration
[PowerSync] FINE: 2026-04-23 13:30:22.518909: Credentials: PowerSyncCredentials<endpoint: http://localhost:8051 userId: null expiresAt: null>
[PowerSync] FINE: 2026-04-23 13:30:22.563678: Validated and applied checkpoint

(notice the 5 seconds delay between "Ending Rust sync" and "Starting Rust sync"

Workaround we found: passing SyncOptions(retryDelay: Duration(milliseconds: 50)) to db.connect restores the old timing: drops from 5000 ms → 700 ms.

If it's normal behavior and we are expected to tweak the retryDelay in test environment, feel free to close this issue :-)

[simolus3]

Thank you, I can reproduce the same issue in one of our tests. There definitely shouldn't be a retry delay in a reconnect when we change streams, so that's a bug.