PowerSync Changelog: June & July 2026

In the last edition I wrote about overhauling and shipping v2.0 of our Dart SDK. It's important to us that PowerSync is well-maintained, so this time we extended that effort to our JavaScript SDKs. We tackled a long laundry list of DX issues and released v2.0 of our web, React Native, Capacitor and Node.js SDKs. More on that in the feature story below.

Beyond that, we added support for new source databases (Azure DocumentDB and Convex), released an official Terraform provider, and shipped some of the most substantial community contributions we've had yet. Community members adding non-trivial features is becoming a trend, and we love it.

Product updates shipped

PowerSync Service:

• Azure DocumentDB as a source database: DocumentDB (formerly Azure Cosmos DB for MongoDB vCore) now works through our existing MongoDB connector: link your connection string and PowerSync detects it automatically. Release notes.
• Convex as a source database: Building with Convex and need offline support? You can now connect your Convex database to PowerSync. Writes still go through your existing Convex mutations, and each client only syncs the data it needs. It's an experimental release, and your feedback shapes where we go from here. Release notes and design notes.
• Sync Streams hardening: The compiler now warns about queries that can silently sync rows under the wrong name (unquoted JOIN aliases, SELECT * after an aliased column). We also fixed several cases where our evaluator diverged from SQLite semantics (thanks @sravan27!). Changelog.

Client SDKs:

• JavaScript SDKs v2.0: Focused on a more stable and intuitive public API, and simpler setup. See the feature story below or review the release notes for a complete summary and how to handle breaking changes.
• Multi-process SQLite access (Swift v1.15.0): App Extensions and App Groups are now supported: the database can live in an App Group container, with the SDK coordinating access between your app and its widgets or extensions. This is an early release with known footguns. We have an intuition that better DX is possible here, but we need your feedback to shape this. Release notes and Docs.
• In-memory databases for the web (v1.39.0): WASQLiteVFS.InMemoryVFS keeps the whole database in memory with no persistence, which is useful for local development and online apps. Docs.
• Bring your own HTTP client (Dart/Flutter v2.3.0): SyncOptions.httpClient lets you add headers, trust self-signed certs, or swap in a faster client like cronet_http. SQLCipher is also back as a native encryption option. Docs.
• Room 3.0 (Kotlin v1.14.1): Our Room integration for Kotlin now uses Room 3.0. This is a breaking change: update your project to Room 3.0 when upgrading to v1.14.1. Docs.

Tools:

• Official Terraform provider: Manage PowerSync Cloud projects and instances as Infrastructure-as-Code. Release notes.
• Custom roles and permissions (Dashboard): Team and Enterprise customers can now create and assign custom Dashboard roles themselves, with project and instance scoping and fine-grained permissions. Previously this had to be configured by our team. Docs.
• More ways to search instance logs (Dashboard): Building on May's searchable logs release, we added additional quality-of-life improvements such as excluding terms with a - prefix and clicking a timestamp to set the range start or end. Docs.
• Smarter CLI commands (v0.10.0): Commands that take --instance-id now resolve the project and org from it automatically (previously you had to add these as flags yourself). Docs.

New demos & guides:

• It's easier than ever to add your own source DB connector to PowerSync. Steven documented how replication in the PowerSync Service works — knowledge that until now mainly lived in people's heads.
• Supported platforms reference — we fleshed out this page to include more detail, like minimum platform versions per SDK, so you can quickly check whether PowerSync runs on your target platform.
• .NET attachments demo — the MAUI To-Do demo now also shows offline-first file syncing with the attachment APIs from v0.1.2.
• Load custom SQLite extensions — how to load custom SQLite extensions into the client-side database.

Community feed

• Conrad wrote about how we built our internal company brain: data from 14+ systems aggregated into Postgres, synced to local SQLite with PowerSync, and queried by agents from Slack, a CLI, or fully offline with local models. Read the post.
• Manrich shared the dogfooding story of rebuilding the PowerSync Dashboard on our own sync engine. Read the post.
• Dean, Christiaan, Steven, and Simon manned our booth at Local-First Conf in Berlin. Thanks to everyone who came to chat! Talks are on YouTube.
• @sravan27 fixed several cases where Sync Streams evaluation diverged from SQLite semantics, which could silently sync the wrong rows (json_each, division by zero, signed casts, alias warnings). Disclosure: most of this came out of a paid hardening sprint we ran with Sravan. Thank you for the solid work.
• @asiergmorato added multi-process database support to the Swift SDK, which became the App Groups feature (PR #147). He needed it for his own app, Fitwoody. Also thank you for your Swift Data integration, which lets Swift Data models persist and sync through PowerSync.
• @mandrade2 tried out our Tauri integration tests, hit an error running them in Vitest's iframe, fixed it in PR #991, and we've since updated the post with his fix. We love this kind of feedback loop, thank you!
• Thank you also to @henriquekraemer, @marioortizmanero, @rumitvn, @delagen, @sincraianul, @daniel-vacic, @Ishant5436, @shenlong-tanwen, and @VIVAAN-DHAWAN for your contributions — we're seeing more and more substantial features and fixes from the community and are loving it.
• Yahya (@whygee-dev) built powersync-mdbx, a research reimplementation of the PowerSync replication protocol in Rust + MDBX, with promising benchmarks. It's not a drop-in replacement today, but as Ralf put it: "It's a very good observation that the PowerSync model fits quite well into a KV store, and does not need a full database like MongoDB or Postgres." The thread is in #engineering-discussions.
• New proposal: SQLite as sync bucket storage. Steven is experimenting with SQLite (and MySQL) as bucket storage options, which would let self-hosted setups run the PowerSync Service without a separate MongoDB or Postgres storage database.
• New proposal: Connection count & error metrics. This would add a counter to our existing sync API metrics for the total number of completed sync connections, labelled by outcome, error code, close reason, and transport. You'd then be able to answer questions like "were there recent sync error spikes?" with a simple Prometheus query.

Feature story: JavaScript SDKs v2

Over time, our JavaScript SDKs accumulated a lot of DX issues, and more recently AX issues too. So we took a step back and asked: what would make these SDKs better to work with and contribute to, for both humans and agents? We kept looking at the public API itself. @powersync/common exposed the SDK's internals alongside its public classes, so routine changes on our side could break existing builds or produce confusing type errors. Taking AbstractPowerSyncDatabase as an example, which was both a class and an effective public interface: even adding a method to it counted as a breaking change under TypeScript's structural rules.

The day-to-day ergonomics had rough edges too. The options you passed to PowerSyncDatabase were spread across a nested chain of interfaces, so there was no single place to see what was available. The database field accepted a DBAdapter, an SQLOpenFactory, or open options all at once, so autocomplete showed every DBAdapter method instead of the options you wanted. The js-logger dependency caused problems when bundling. And WebSocket support was bundled whether you used it or not, which was not cheap: it relied on RSocket, whose packages are around 500 kB and need a custom build step to work outside Node.js.

None of these were dealbreakers on their own, but together they made the SDKs harder to work with than they should be. And not just for people: coding agents tripped over the same confusing types and scattered options. So we fixed the foundation. Benefits of the JavaScript SDKs v2.0 release include:

• A cleaner, more stable API, with only public interfaces exposed and implementation details in a separate package
• Simpler setup, with one clearly-typed set of options for the database, and one for connect()
• Logging as a small PowerSyncLogger interface rather than a separate dependency
• Smaller bundles, with WebSockets loaded lazily and the two web workers merged into one
• OP-SQLite built into @powersync/react-native as the default driver, replacing React Native Quick SQLite

There are breaking changes, but for most apps the upgrade is a few mechanical edits to how you construct the database, connect, and set up logging. The release notes walk through every one. A lot of what went into v2.0 came straight out of your feedback and sharing how you're using these SDKs. Please keep it coming.

That's it for this issue.