PowerSync Philosophy
Our vision at PowerSync is that an offline-first app architecture should be easier for the developer than cloud-first, and give a better experience for the end user — even when they're online.
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 [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 Postgres 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 on the server — no extensions, and no significant change in your schema required [2]. We use the Postgres WAL 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. 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.
[2] In some cases denormalization is required to effectively partition the data to sync to different users.
Last updated