FAQ

Frequently Asked Questions

​
Question
Answer
How is a client-side sync triggered? Does the SDK use polling or real-time sync?
PowerSync uses near real-time streaming of changes to the client (< 1s delay).
​
A persistent connection is used to continuously stream changes to the client.
The is implemented using a standard HTTP/2 request with a streaming response, or websockets.

A polling API will also be available for cases where the client only needs to update data periodically, and prefer to not keep a connection open.
​
The real-time streaming is not designed for "update as you type" - it still depends on explicitly saving changes. Real-time collaboration is supported as long as users do not edit the same data (same columns of the same rows) at the same time.

Concurrently working on text documents is not supported out of the box. This is solved better by CRDTs, which PowerSync may support in the future.
What data volumes are supported?
The sync system is designed to efficiently sync around 1,000,000 rows, or 1GB of uncompressed data. More would be possible, but performance may degrade.

Initial bulk data download should handle 2,000 - 10,000 rows / second (2-10MB/s, or 1 minute 30 seconds - 10 minutes for 1,000,000 rows), depending on the device performance.

After the initial bulk download, only changes (new / updated / deleted rows) are synchronized, at similar rates to above. Note that since PowerSync stores some history for each row (sync tables), the system is not designed to continuously handle this many updates/second. 
What happens when a user is offline for a long time?
The user may need to re-download more data than for incremental updates, but this should not be very significant.
​
Changes recorded on the client but not uploaded yet will never expire, unless the queue is explicitly cleared.
Can a client track whether changes have been processed?

For example, a new record should not be displayed until the server received it, or it should be displayed as pending, or the entire screen must block with a spinner.

While PowerSync does not have out-of-the-box support for this due to the great variety of requirements, this is easy to build on top of the sync system.

A simple approach is to store a “status” or “pending changes” column on the table, and set that whenever the client makes a change. When the server receives the change, it then sets it to “processed” / “no pending changes”. So when the server has processed the change, the client automatically syncs that status back.

For more granular information, record individual changes in a separate table, as explained in Custom Conflict Resolution.

Note: Blocking the entire screen with a spinner is not recommended, since the change may take a very long time to be processed if the user is offline.
I don’t have direct database access, and can only access data via an API. Can I use PowerSync for this?
Right now, we don’t have support for replicating data via APIs. A workaround would be to have custom code to replicate the data from the API to a PostgreSQL instance, then sync that with PowerSync.
We may add a way in the future to replicate the data directly from an API to the PowerSync cloud service, without a database in between.
Are “live queries” supported?
Yes.
​
The client SDK supports real-time streaming of changes, and can automatically rerun a query if the underlying data changed.
​
It does not support incrementally updating the result set yet, but it should be fast if the query is indexed appropriately, and the result set is small enough.
What features are available for debugging issues?
This depends a lot on the type of issue:
1.Connection issues between client and server: We provide diagnostics via an API on the client (e.g. currently connected, last completed sync time, queue size).
2.Data lagging behind on PowerSync service. Roadmap.
3.Expected data not appearing on device: Roadmap.
4.Writes to the backend database failing: PowerSync is not actively involved: use normal debugging techniques (server-side logging; client and server-side error tracking).
Are transactions supported?
Client-side transactions are supported, and use standard SQLite locking to avoid conflicts.
​
Client-server transactions are not supported. This would require online connectivity to detect conflicts and retry the transaction, which is not possible for changes made offline. Instead, it is recommended to model the data to allow atomic changes (see previous sections on conflict detection).
Can auto-incrementing IDs be used?
This is generally not recommended, but it can be used in some cases, with caveats.
​
See the section on client ID for details.
Can attachments (files) be synced?
The initial version does not cater for large attachments out of the box. Smaller files can be stored as base64-encoded data, but this is not recommended for larger files (around 1MB+).
​
An attachment sync or caching system can be built on top of PowerSync. PowerSync can be used to sync the id and other metadata, and then the app can download the attachments — either upfront or on demand.
My backend application uses GraphQL. Can I use PowerSync?
GraphQL is currently not supported. REST APIs are required on the backend application for use by the PowerSync SDK
Is the system susceptible to SQL Injection?
No. Firstly, the PowerSync execute API is parameterized. Secondly, since only a subset of data is synchronized to clients via Sync Rules, even if a flaw was exploited, only the data on the device could be queried in this way. 
​

Question	Answer
How is a client-side sync triggered? Does the SDK use polling or real-time sync?	PowerSync uses near real-time streaming of changes to the client (< 1s delay). A persistent connection is used to continuously stream changes to the client. The is implemented using a standard HTTP/2 request with a streaming response, or websockets. A polling API will also be available for cases where the client only needs to update data periodically, and prefer to not keep a connection open. The real-time streaming is not designed for "update as you type" - it still depends on explicitly saving changes. Real-time collaboration is supported as long as users do not edit the same data (same columns of the same rows) at the same time. Concurrently working on text documents is not supported out of the box. This is solved better by CRDTs, which PowerSync may support in the future.
What data volumes are supported?	The sync system is designed to efficiently sync around 1,000,000 rows, or 1GB of uncompressed data. More would be possible, but performance may degrade. Initial bulk data download should handle 2,000 - 10,000 rows / second (2-10MB/s, or 1 minute 30 seconds - 10 minutes for 1,000,000 rows), depending on the device performance. After the initial bulk download, only changes (new / updated / deleted rows) are synchronized, at similar rates to above. Note that since PowerSync stores some history for each row (sync tables), the system is not designed to continuously handle this many updates/second.
What happens when a user is offline for a long time?	The user may need to re-download more data than for incremental updates, but this should not be very significant. Changes recorded on the client but not uploaded yet will never expire, unless the queue is explicitly cleared.
Can a client track whether changes have been processed? For example, a new record should not be displayed until the server received it, or it should be displayed as pending, or the entire screen must block with a spinner.	While PowerSync does not have out-of-the-box support for this due to the great variety of requirements, this is easy to build on top of the sync system. A simple approach is to store a “status” or “pending changes” column on the table, and set that whenever the client makes a change. When the server receives the change, it then sets it to “processed” / “no pending changes”. So when the server has processed the change, the client automatically syncs that status back. For more granular information, record individual changes in a separate table, as explained in Custom Conflict Resolution. Note: Blocking the entire screen with a spinner is not recommended, since the change may take a very long time to be processed if the user is offline.
I don’t have direct database access, and can only access data via an API. Can I use PowerSync for this?	Right now, we don’t have support for replicating data via APIs. A workaround would be to have custom code to replicate the data from the API to a PostgreSQL instance, then sync that with PowerSync. We may add a way in the future to replicate the data directly from an API to the PowerSync cloud service, without a database in between.
Are “live queries” supported?	Yes. The client SDK supports real-time streaming of changes, and can automatically rerun a query if the underlying data changed. It does not support incrementally updating the result set yet, but it should be fast if the query is indexed appropriately, and the result set is small enough.
What features are available for debugging issues?	This depends a lot on the type of issue: 1. Connection issues between client and server: We provide diagnostics via an API on the client (e.g. currently connected, last completed sync time, queue size). 2. Data lagging behind on PowerSync service. Roadmap. 3. Expected data not appearing on device: Roadmap. 4. Writes to the backend database failing: PowerSync is not actively involved: use normal debugging techniques (server-side logging; client and server-side error tracking).
Are transactions supported?	Client-side transactions are supported, and use standard SQLite locking to avoid conflicts. Client-server transactions are not supported. This would require online connectivity to detect conflicts and retry the transaction, which is not possible for changes made offline. Instead, it is recommended to model the data to allow atomic changes (see previous sections on conflict detection).
Can auto-incrementing IDs be used?	This is generally not recommended, but it can be used in some cases, with caveats. See the section on client ID for details.
Can attachments (files) be synced?	The initial version does not cater for large attachments out of the box. Smaller files can be stored as base64-encoded data, but this is not recommended for larger files (around 1MB+). An attachment sync or caching system can be built on top of PowerSync. PowerSync can be used to sync the id and other metadata, and then the app can download the attachments — either upfront or on demand.
My backend application uses GraphQL. Can I use PowerSync?	GraphQL is currently not supported. REST APIs are required on the backend application for use by the PowerSync SDK
Is the system susceptible to SQL Injection?	No. Firstly, the PowerSync `execute` API is parameterized. Secondly, since only a subset of data is synchronized to clients via Sync Rules, even if a flaw was exploited, only the data on the device could be queried in this way.

Resources - Previous

Roadmap

Next - Resources

Known Issues and Limitations

Last modified 1mo ago