Comment on page
The service and client SDK operate in unison to keep client-side SQLite databases in sync with a server-side SQL database.
PowerSync is designed to support any combination of backend database and frontend software framework, with additional backend database support and SDKs on the way.
Before using PowerSync, an application's existing architecture may look like this:
The PowerSync client SDK uses the retrieved JWT to authenticate directly against the PowerSync service:
From the client-side perspective, there are two data flow paths:
- reading data from the server or downloading data
- writing changes back to the server, or uploading data.
App clients always read data from a local database. The local database is asynchronously hydrated from the PowerSync service.
A developer configures sync rules for their PowerSync instance to govern which data is synced to which users. The PowerSync service connects directly to Postgres databases and uses the Postgres Write-Ahead-Log (WAL) to hydrate dynamic and contextual data partitions, called sync buckets. Sync buckets are used to partition data according to the configured sync rules. (In most use cases, only a subset of data is required in a client's database and not a copy of the entire Postgres database.)
Client-side data modifications, namely updates, deletes and inserts, are persisted in the embedded database as well as stored in an upload queue. The upload queue is a blocking FIFO queue that gets processed when network connectivity is available. Each entry in the queue is processed by writing the entry to the developer's existing backend application API. This is to ensure that existing backend business logic is honored when uploading data changes. For more information, see the section on integrating with your backend.