PowerSync Blog

Author here!

Surprised to see this on the front page again (hello fellow pottery enthusiasts?), but figured this could be a good chance to address some of the comments from the recent discussion [0] since I missed it last time :P

The most common feedback seemed to be, "this is dumb, just use SQLite", which is definitely valid.

This was actually how I initially started building the app (using SQLite), and it worked pretty well. There were a couple reasons I abandoned this approach though: one, whenever I had to uninstall and reinstall the app, the data would get wiped; two, I still had to deal with migrations and other annoying boilerplate; and three, I wanted to be able to share my results with my friends in a read-only web view.

(That being said, I'm also curious to explore how tools like ElectricSQL [1], PowerSync [2], TinyBase [3], etc. play with SQlite to handle some of these issues. At a glance, it just seemed like these would require more time to setup compared to InstantDB [4].)

Another similar comment that popped up a few times was the idea that if I'm trying to model _relational_ data, it would be ridiculous to use anything other than a _relational_ database.

I think that's fair, but I also think it's fair to say a graph database is also "relational" in some sense, or at least "relationship-centric" [5] :)

Either way, I had a lot of fun with this. And I was definitely optimizing more for speed/scrappiness than for doing it The Right Way, so if anyone has any…

I'm interested in this problem also!

I think there is a large overlap with projects that market/focus on offline-first experiences.

AFAIK this problem can be solved by:

1) Considering a client-side copy of the database that gets synced with the remote DB. This is an approach [PowerSync](https://www.powersync.com/) and [ElectricSql](https://electric-sql.com/) and [rxdb](https://rxdb.info/) take! For the first two, they effectively use postgres CDC and then have a sync process that is provided for you. For rxdb I think you have to roll your own syncing but there is an interface for you to implement.

One difference between ElectricSQL and PowerSync (copied this from another [HN comment](https://news.ycombinator.com/item?id=37600917)) -> `ElectricSQL uses “shapes” (currently a WIP feature) defined on the client to partition data, while PowerSync uses server-side “sync rules”. The sync rules approach allows data to be transformed and filtered using basic SQL queries, which [PowerSync] expect to scale well (benchmarks pending). PowerSync guarantees consistency over all synced data, while it appears like ElectricSQL only guarantees consistency within each shape. PowerSync also automatically adds and removes sync buckets when changes are made to either the sync rules or data, while ElectricSQL likely requires you to subscribe and remove shapes yourself.`

^ Please note that comment faced rebuttal from ElectricSQL. On the same thread (6 months ago) , someone from ElectricSQL…

I would suggest checking out PowerSync (https://www.powersync.com/) for this.

I've built various React apps (and iOS apps before that) in the past on a bunch of stacks.

My experience with the following tools were as follows:

- Pusher: love the tool, but required lots of layers on top of it to be used for keeping DB's in sync. It does make sockets trivially easy to get going and use.

- MeteorJS: lots of cool "realtime magic", but hard to break out (it's too opinionated and constrained). We ended up breaking out and running ExpressJS + React + Pusher and ditching MeteorJS.

- Firebase: used it for two projects. Platform lock-in, like weird Firebase-specific nuances to workaround and solve for, felt like quite a lot. You basically have to park your experience with other stacks and databases and become an expert in Firebase. A big one here was around access policies for the data in the database → limiting what data a user can access.

My current stack is now mostly Cloudflare and keeping real-time requirements in the product design to a minimum, to reduce the overhead.

in case anyone finds this useful, here's the slowly growing collection of links to similar tools:

https://tinybase.org/

https://www.evolu.dev/

https://replicache.dev/

https://fireproof.storage/

https://vlcn.io/

https://www.instantdb.com/

https://loro.dev/

https://electric-sql.com/

https://docs.y-sweet.dev/

https://syncedstore.org/docs/

https://collabs.readthedocs.io/en/latest/

https://remotestorage.io/

https://rxdb.info/offline-first.html

https://github.com/siriusastrebe/jsynchronous

https://www.powersync.com/

https://pouchdb.com/

https://jazz.tools/

https://www.triplit.dev/

https://automerge.org/

https://www.dxos.org/

I hope one day to try them all :-) Or read a summary from someone who does.

We now have absurd-sql, wa-sqlite, and the official SQLite project all running in a browser. Their tradeoffs are discussed here https://www.powersync.com/blog/sqlite-persistence-on-the-web

That article was written in July, and in the intervening time, Chrome's announced an intent to ship "Multiple Readers and Writers in File System Access API" aka `readwrite-unsafe` [0] in v121 (stable in 2 weeks) which could help improve SQLite's performance even more.

[0] https://chromestatus.com/feature/5172892632875008

Edit: It looks like wa-sqlite already has a prototype VFS taking advantage of the above feature https://github.com/rhashimoto/wa-sqlite/discussions/116

Cool, makes sense. We still want to write a blog post about how we built powersync that will go into more detail on the points you raised.

The one thing I'll add is we found "keeping UI responsive while syncing in the background" is highly platform dependent since all platforms have their quirks, but for React Native we have a detailed blog post and code (admittedly tightly coupled to powersync, but should provide a starting point) https://www.powersync.com/blog/keep-background-apps-fresh-with-expo-background-tasks-and-powersync