​
What PowerSync means for end-users

The app just works, whether fully online, fully offline, or with spotty connectivity.

The app is always fast and responsive — no need to wait for network requests.

​
What PowerSync means for the developer

For the developer, the goal of PowerSync is to solve the hard problems of keeping data in sync, then get out of the way.

You use a standard Postgres, MongoDB or MySQL [1] database on the server, a standard SQLite database on the client, and your own backend to process writes. PowerSync simply keeps the SQLite database in sync with your backend/server database.

​
State Management

Once you have a local SQLite database that is always in sync, state management becomes much easier:

  • No need for custom caching logic, whether in-memory or persisted.
  • No need for maintaining in-memory state across the application.

All state is in the local database. Queries are reactive — updating whenever the underlying data changes.

​
Flexibility

PowerSync allows you to fully customize what data is synced to the client. Syncing the entire database is extremely simple, but it is just as easy to use our Sync Rules to transform and filter data for each client (dynamic partial replication).

Writing back to the backend is in full control of the developer — use your own authentication, validation, and constraints.

Our goal is also to be stack-agnostic: whether you are switching from MySQL to Postgres, from Flutter to React Native, or using multiple different stacks — our aim is to maintain maximum engineering optionality for developers.

​
Performance

SQLite is fast. It can perform tens of thousands of updates per second, even faster reads, with seamless support for concurrent reads. Once you get to filtering through thousands of rows in queries, indexes keep the queries fast.

​
Simplicity

You use plain Postgres, MongoDB or MySQL on the server — no extensions, and no significant change in your schema required [2]. We use the Postgres WAL, MongoDB change streams or MySQL binlog to replicate changes to the PowerSync Service, where data is transformed and partitioned according to Sync Rules, and persisted in a way that allows streaming incremental changes to each client.

PowerSync has been used in apps with hundreds of tables. There are no complex migrations to run: You define your Sync Rules and client-side schema, and the data is automatically kept in sync. If you change Sync Rules, the entire new set of data is applied atomically on the client. When you do need to make schema changes on the server while still supporting older clients, we have the processes in place to do that without hassle.

No need for CRDTs [3]. PowerSync is a server-client sync platform — since no peer-to-peer is involved, CRDTs can be overkill. Instead, we use a server reconciliation architecture with a default approach of “last write wins”, with capability to customize the conflict resolution if required — the developer is in full control of the write process. Our strong consistency guarantees give you peace of mind for the integrity of data on the client.

​
See Also

​
Footnotes

  • [1] Support for more databases planned. See our roadmap for details.
  • [2] In some cases denormalization is required to effectively partition the data to sync to different users.
  • [3] If you want to use CRDTs for fine-grained collaboration like text editing, we have examples of how to do that in conjunction with PowerSync, storing CRDT data in Postgres.

Was this page helpful?

PowerSync OverviewQuickstart / Overview