PowerSync Overview
PowerSync is currently in Beta, and is suitable for production use provided that appropriate testing is done to ensure that performance meets the requirements of your specific use case
PowerSync is a cloud service that keeps backend SQL databases in sync with on-device databases embedded in an SDK.
The cloud service and client SDK operate in unison to keep client-side 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 cloud service uses database native credentials and authenticates directly against a PostgreSQL database using the configured credentials:
When the PowerSync client SDK is included in an app project, it uses existing app to backend authentication to retrieve a JSON Web Token (JWT):
The PowerSync client SDK uses the retrieved JWT to authenticate directly against the PowerSync cloud 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 cloud service.
A developer configures sync rules for their PowerSync instance to govern which data is synced to which users. The PowerSync cloud service connects directly to PostgreSQL databases and uses the PostgreSQL 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 PostgreSQL database.)
The local SQLite database embedded in the PowerSync SDK is automatically kept in sync with the backend SQL database, based on the sync rules configured by the developer:
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.
Last modified 1mo ago