Sync / CRDT plugins

[jeroenptrs]

Is your feature request related to a problem? Please describe.
For local first apps, sync is an important aspect. I've been looking for something that does just enough. Most sync services are focused on realtime/multiplayer/collaboration on top of just sync.

Describe the solution you'd like
Mainly riffing on the post I read on the starbase blog about 2 way sync, with Websockets being available this could introduce not just sync as a plugin but also realtime collaborative features?

Describe alternatives you've considered
I think a potential alternative to real time would be to use Change Data Capture in a similar way to how services like Ably / Supabase / Powersync hook into Postgres events? Not sure how much of that fits within Starbase but from the couple hours of play I had with the codebase I also don't really see why it couldn't!

Additional context
Databases are not my strong suit, so I don't know what makes sense and what doesn't 😅

[Brayden]

This makes total sense and fits very closely to what we are experimenting with internally as well. There has been a lot of people asking for syncing capabilities. Do you mind outlining what your use case would ideally look like for a plugin like this?

For example, not sure if you're exporting the SQL dump from Starbase and using that to power a local database, then looking to use WebSockets to send mutations back up to the managed instance? Would you want/need a Javascript/Typescript library locally that does the data interactions for you between a Starbase <> local SQL file? Or is the ask something different altogether?

Would love to make sure I'm being as inclusive as possible with syncing use cases as I hear them! cc: @jeroenptrs

[jeroenptrs]

Re sync: my biggest question there is how much sense checkpoint based / partial syncs would be of interest. Both in terms of

• for example durable objects as an edge instances providing read replicated data / instantiating a subset of a different database close to the user (not sure whether that should be always read only or can flow back upstreamn let alone the feasibility of that)
• a "single-player" local-first app (like a personal budgeting app) that also has a dashboard for metrics somewhere on a display like TRMNL for example, which is most likely read-only in my use case, but I can imagine multi-device use cases that would then again make it multiplayer, but in this case I might want to be able to choose when I want to sync

Those are some of the use cases I've been thinking of both in trying to understand DO's and working with local first tools. Those can, on the client side, receive a sqlite file however (most React Native examples use sqlite under the hood for sync) so bootstrapping it with an sqlite export do make sense, but would then fall under the notion of being always connected.

That's why syncing a (partial) state, of potentially having missed mutations, could also make sense for me, but seems daunting from an architectural point of view. That said, starbase does have a leg up for me in being able to stream over websockets built-in, it makes a good foundation for local first tools, and the power (and potential to be synchronous) of sqlite in DO's might mean that you're not expecting your server to also hold most/all of your db in memory, like some local first tools appear to work under the hood.