I have also tried supabase + powersync, In my test environment while syncing 6K rows for a single user between two devices consumed 145K sync operations on powersync and we have 1M free sync ops per month.
So just think about it how quickly we will hit that limit, so I dropped powersync and starting using brick.
about the file sync helper, I just finished writing its code.
the idea is based on the Supabase, we have to use realtime table.
On device 1 user will upload the file,
the attachment metadata record is created and stored in brick, that will be synced to the supabase if the network is available.
the file will saved on the local first, then if the network is available file will be uploaded directly,
there are file_local_sync_status and file_remote_sync_status.
if the network is not available then the file queue request is stored separately on the sqlite
so on device 2: is the network is available:
since the realtime is enabled service will receive the metadata file.
it will check the remote sync status: is it is uploaded, then on network availability file will get downloaded.
and there are other statuses like: upload_failed, deleted, remote_uploade_in_progess etc
After my initial tests, I will make the code public.
currently sync_helper is tightly coupled with the supabase and brick.
We can easily make it abstract by making the realtime code abstract,
making remote file storage abstract will help us plugging the sync service with other platforms like firebase or s3. You got the point right.
I haven’t written unittests yet as there is a lot of work pressure going on.
thanks
