ochiba

I did the exact same thing for our “company brain”. Works great

PowerSync supports OPFS as SQLite VFS since earlier 2025: https://github.com/powersync-ja/powersync-js/pull/418

This is great to see and I like the simplicity of the approach. You can also look at PowerSync (which I work on). It's in a similar space as ElectricSQL. It syncs to SQLite on the client-side and provides built-in reactivity. On the web, it uses wa-sqlite with either OPFS or IndexedDB. It also takes care of things like multi-tab on web, and queueing and uploading client-side mutations to the backend.

This site also has a directory of devtools: https://lofi.so/

You can look at PowerSync: https://www.powersync.com/

Realm's sync functionality (Atlas Device Sync) has been deprecated by MongoDB: https://www.mongodb.com/docs/atlas/app-services/sync/device-...

I really enjoyed the talk at Local-First Conf today — well done. I thought it was very well explained and made compelling arguments for the event-sourcing materialized into SQLite architecture.

Thank you for championing SQLite and especially OPFS Wasm SQLite on the web — we (PowerSync) are clearly also big proponents of it, so love to see other projects having success with it too.

I am not sure about Turso but I've seen a few different approaches to this with other sync engine architectures:

1. At a database level: Using something like RLS in Postgres

2. At a backend level: The sync engine processes write operations via the backend API, where custom validation and authorization logic can be applied.

3. At a sync engine level: If the sync engine processes the write operations, there can be some kind of authorization layer similar to RLS enforced by the sync engine on the backend.

It's definitely quite a hard engineering problem to solve, if you try to cover a wide range of use cases, and layer on top of that things like permissions/authorization and scalability

There are niche use cases where the former (work for days to weeks offline) are useful and even critical - like certain field service use cases. Surviving glitches in network connectivity is useful for mainstream/consumer applications for users in general, especially those on mobile.

In my experience, it can affect the architecture and performance in a significant way. If a client can go offline for an arbitrary period of time, doing a delta sync when they come back online is more tricky, since we need to sync a specific range of operation history (and this needs to be adjusted for specific scope/permissions that the client has access to). If you scale up a system to thousands or millions of clients, having them all do arbitrary range queries doesn't scale well. For this reason I've seen sync engines simply force a client to do a complete re-sync if it "falls behind" with deltas for too long (e.g. more than a day or so.) Maintaining an operation log that is set up and indexed for querying arbitrary ranges of operations (for a specific scope of data) works well.

Yes, exactly. https://www.gabrielgambetta.com/client-side-prediction-serve...

I would say this is why server-authoritative systems that allow for custom logic in the backend for conflict resolution work well in practice (like Replicache, PowerSync and Zero - custom mutators coming in beta for the latter). Predefined deterministic distributed conflict resolution such as CRDT data structures work well for certain use cases like text editing, but many other use cases require deeper customizability based on various factors like you said.

Useful directory of tools here: https://localfirstweb.dev/

> Yes, they are fascinating and yes they solve real problems but they are absolute overkill to your problems (except collab editing), at least currently. Why? Because they are all about conflict resolution. You can get very far without addressing this problem: for instance a cache, like you mentioned, has no need for conflict resolution. The main data store owns the data, and the cache follows. If you can have single ownership, (single writer) or last write wins, or similar, you can drop a massive pile of complexity on the floor and not worry about it. (In the rare cases it’s necessary like Google Docs or Figma I would be very surprised if they use off-the-shelf CRDT libs – I would bet they have an extremely bespoke and domain-specific data structures that are inspired by CRDTs.)

I agree with this. CRDTs are cool tech but I think in practice most folks would be surprised by the high percentage of use cases that can be solved with much simpler conflict resolution mechanism (and perhaps combined with server reconciliation as Matt mentioned). I also agree that collaborative document editing is a niche where CRDTs are indeed very useful.

> And 'synchronisation' as a practice gets very little attention or discussion. People just start with naive approaches like 'download whats marked as changed' and then get stuck in the quagmire of known problems and known edge cases (handling deletions, handling transport errors, handling changes that didn't get marked with a timestamp, how to repair after a bad sync, dealing with conflicting updates etc).

I've spent 16 years working on a sync engine and have worked with hundreds of enterprises on sync use cases during this time. I've seen countless cases of developers underestimating the complexity of sync. In most cases it happens exactly as you said: start with a naive approach and then the fractal complexity spiral starts. Even if the team is able to do the initial implementation, maintaining it usually turns into a burden that they eventually find too big to bear.

I think that is where sync engines come in that allow doing arbitrary hybrid queries (across local and remote data) and then keeping the results of those hybrid queries in sync on the client.

This is one of the ideas that appears to be central to the genesis of Zero [1]

ElectricSQL allows for a similar pattern and PowerSync is also working on this [2]

[1] https://www.youtube.com/watch?v=rqOUgqsWvbw

[2] https://www.powersync.com/blog/powersync-2025-roadmap-sqlite...

We are working on this: https://www.powersync.com/

We started with Postgres and added support for MongoDB after they deprecated Atlas Device Sync in September last year.

Not sure if you've looked at PowerSync yet: https://www.powersync.com/ (I'm on the team)

For the read path it hooks into Postgres logical replication or MongoDB change streams (and MySQL binlog soon). It supports partial syncing using declarative rules. For the write path, it allows writing to the local SQLite database and also places writes into an upload queue, and then uses a developer-defined function to upload writes to the backend API.

We did a deep dive on current options for SQLite on the web, and are currently using an IndexedDB-based VFS, and looking to move to OPFS: https://www.powersync.com/blog/sqlite-persistence-on-the-web

We recently released an integration with TanStack Query to allow leveraging some of its features in conjunction with PowerSync: https://docs.powersync.com/client-sdk-references/js-web/java...

> Meanwhile for “local-only” it would be great to use sqlite in the browser + native file system API so that the db could be stored on the user’s file system and we wouldn’t have to worry about browser storage eviction. i think that could really open up a whole world of privacy preserving offline software delivered through the browser

Agreed. This is a limitation of IndexedDB and OPFS as persistent browser storage currently

Yes, using IndexedDB is common, and increasingly also running SQLite in the browser using Wasm, with its data persisted through a VFS that uses IndexedDB or OPFS. https://www.powersync.com/blog/sqlite-persistence-on-the-web

Local-first generally refers to apps that work with a local client database which syncs with a server database in the background. Reads and writes go to the local database first. This results in very low latency and not being dependent on the network for working with data. The term is often applied loosely and architectures and implementations differ quite a bit.

This community has been central to the idea of local-first: https://localfirstweb.dev/

The term local-first was coined by Martin Kleppmann et al in this essay: https://www.inkandswitch.com/local-first/

There is a fairly comprehensive list of frameworks/tools here: https://localfirstweb.dev/

I work on PowerSync and we did a Show HN last year: https://news.ycombinator.com/item?id=38473743

Also see InstantDB Show HN: https://news.ycombinator.com/item?id=41322281

This made the rounds on HN recently: https://tonsky.me/blog/crdt-filesync/

A PoC of using Dropbox for a local-first app

> Now, that functionality with their rewrite is somewhat removed, as they expect you to handle clientside writes by yourself, which is what I believe PowerSync does as well, am I correct in that understanding?

Yes, that is correct.

> If I wanted a fully offline clientside database that could then sync to all the other clients when online, what would I do? I am looking for this in the context of a Flutter app, for reference.

This is what PowerSync provides by default. If you haven't done so yet, I would suggest starting with our Flutter client SDK docs and example apps — and feel free to ask on our Discord if you have any questions or run into any issues :)

Makes sense. FWIW, there are some more details here: https://replicache.notion.site/Introducing-Zero-8ce1b1f184aa...

Thanks, appreciate the feedback.

Sounds conceptually similar to Zero: https://zerosync.dev/

I haven't looked in detail yet — what are the main differences relative to Zero?

Co-founder of PowerSync here. Would love to hear what you would like to see improved in PowerSync :) Thanks!

I work on PowerSync which may be worth looking at too, for Postgres-SQLite sync https://www.powersync.com/

I work on PowerSync which does Postgres-SQLite sync, FWIW: https://www.powersync.com/