Offline-First with CouchDB and PouchDB in 2025 | Hacker News Reader

Offline-First with CouchDB and PouchDB in 2025

neighbourhood.ie

68 pointsfelideon22 comments

PouchDB and CouchDB were what inspired me to build Triplit[1]. The idea of having an identical (or merely similar in the case of Pouch/Couch) query engine accessible on client and server is insanely powerful.

The author links to a much longer post on handling conflicts which is worthy of its length because it's not a pleasant experience with this setup.

I highly recommend trying a modern setup from one of the many new local first solutions [2]

1. https://triplit.dev

2. https://www.localfirst.fm/landscape

Nice, I’ll have to try out Triplit. There’s also Couchbase which has a local sync database in C++ IIRC.

Also, heads up the first triplit link I tried gave me a 404: https://www.triplit.dev/docs/client/query/select#selecting-r...

Great catch, fixed!

Couchbase had a lot of subtle incompatibilities with PouchDB in my attempts to use it on a past project. The big one I recall was that Couchbase had far more restrictions on key names and that required some workarounds.

(Though to be fair Apache has been threatening to shrink the key space greatly as well with the considered move to the Foundation-based "CouchDB 4.0".)

Ah good to know. For my use cases I would probably be looking at Couchbase Lite [1] not PouchDB. I’d be more concerned about file attachment sizes and syncing.

1: https://github.com/couchbase/couchbase-lite-C

That's a related thing I learned from that past project: file attachments are also extremely vulnerable to compatibility issues between CouchDB/PouchDB/Couchbase/Cloudant/etc. Even when they claim to support sizes large enough, they often fail to sync even when small. Attachments in general in the CouchDB protocol are a bottleneck that slows or effectively breaks sync if you have too many to sync at once, because most CouchDB-ish implementations tend to only process a single document at once among other factors.

The project I was working on involved regularly taking some photos and all the sync issues with attachments led to moving to syncing only metadata like width, height, and Blurhashes in the database itself and use a reference URL/pointer to a content-addressed storage (basically an S3 bucket-like with git-like hashes for filenames) we could background sync more directly outside of the CouchDB protocol. (Blurhashes were particularly useful there while waiting on that additional background sync phase after the CouchDB sync.)

triplit sounds awesome. Any precedence of someone using it from a native iOS app?

With React Native yes but not yet with Swift. There's been quite a few requests to my surprise through--I figured CloudKit, etc would be sufficient on iOS but I don't have experience there.

CloudKit not cross platform

How does Triplit compare to InstantDB?

it's fully open-source for once

Instant founder here! We're fully open source :)

https://github.com/instantdb/instant

Great to see the founder of Triplit here! PouchDB was definitely ahead of its time, and it’s exciting to see its legacy being carried forward by so many modern local-first (lo-fi) solutions. I’ve also been a longtime fan of Triplit - its API, docs, and overall DX (plus direct community interaction) are excellent.

Also Triplit's universal client/server model means you never have to care about all the complexity of other solutions that require to get the transformations between client db & server db just right. A really impressive piece of work! (another great one with a universal db is jazz.tools, especially if you need encryption)

Please let's not make lo-fi mean local-first.

Is Triplit overkill (over PouchDB) if multi-user collaboration is not a use case?

I would love to see a sync solution that didn't want to replace my datastore, or mediate all access to it.

This approach means the tools have to be good at not just sync, but also querying, business logic, validation, authn, authz, trigger background jobs, etc. That's a lot!

I'm not trying to eliminate my backend, nor an all-in-one frontend DB. I've tried tools that do that, and I've come to think the approach has severe limits.

I wonder if there's not a way to offer a two-way stream of data change events, with conflict detection/resolution, which I can process with my own code.

WatermelonDB and Replicache both follow this model.

I had quite the offline-firat déjà vu, when I saw local-first trending the last two years.

> Vite, well, it’s in the name. Fast build tooling.

Can someone explain this to me? I’m clearly missing something about its name.

It can mean 'quickly'.

https://en.wiktionary.org/wiki/vite

I used PouchDB w/ CouchDB as the datastore for a digital wallet. Used to store ZKs for proof of age etc.

Worked a treat

CouchDB - is JD Vance a power user?

Reply on news.ycombinator.com