Frequently Asked Questions


What versions of Postgres are supported?

PowerSync supports Postgres 11+

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 — see the CRDTs section.

What data volumes are supported?

See the section on Performance and Limits.

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 service, without a database in between.

Are “live queries” supported?


The PowerSync client SDKs support 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?

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?

An attachment sync or caching system can be built on top of PowerSync. See the section on Attachments for details.

My backend application uses GraphQL. Can I use PowerSync?

Currently, PowerSync can only read from Postgres databases directly.

GraphQL or REST APIs can be used for the write path by the PowerSync SDK

Is the system susceptible to SQL Injection?

By default PowerSync is not susceptible to SQL injection. The PowerSync execute API is parameterized, and as long as developers use that, SQL injection is not possible. It is however the developer's responsibility to ensure that they use the parameterized API and don't directly insert user-provided data into underlying SQLite tables.

When should I use getCrudBatch() instead of getNextCrudTransaction() ?

Use getCrudBatch() when you don't care about atomic transactions, and want to do bulk updates for performance reasons.

Last updated