Skip to main content
In some of those cases, the user may want to register and start syncing data with other devices or users at a later point, while other users may keep on using the app without ever registering or going online.” PowerSync supports these scenarios. By default, all local changes will be stored in the upload queue, and will be uploaded to the backend server if the user registers at a later point. A caveat is that if the user never registers, this queue will keep on growing in size indefinitely. For many applications this should be small enough to not be significant, but some data-intensive applications may want to avoid the indefinite queue growth. There are two general approaches we recommend for this:

​
1. Local-only tables

final table = Table.localOnly(
  ...
)
Flutter + Drift users: If you’re using local-only tables with viewName overrides, Drift’s watch streams may not update correctly. See the troubleshooting guide for the solution.
Use local-only tables until the user has registered or signed in. This would not store any data in the upload queue, avoiding any overhead or growth in database size. Once the user registers, move the data over to synced tables, at which point the data would be placed in the upload queue. The following example implementations are available:
Client frameworkLink
Flutter To-Do List App (with Supabase)supabase-todolist-optional-sync
React To-Do List App (with Supabase)react-supabase-todolist-optional-sync

​
2. Clearing the upload queue

The upload queue can be cleared periodically (for example on every app start-up), avoiding the growth in database size over time. This can be done using: 
DELETE FROM ps_crud
It is up to the application to then re-create the queue when the user registers, or upload data directly from the existing tables instead. A small amount of metadata per row is also stored in the ps_oplog table. We do not recommend deleting this data, as it can cause or hide consistency issues when later uploading the data. If the overhead in ps_oplog is too much, rather use the local-only tables approach.