[salviati]

We tried to use it alongside pouchdb to provide offline first experience. We ran into a lot of issues, mainly with pouchdb bugs. Then after reading this list [1] of issues in the couchdb architecture we decided to ditch it and stop trying to make pouchdb work.

[1] https://news.ycombinator.com/item?id=17115649

[ZuLuuuuuu]

Out of curiosity, if you would like to start a new, offline-first project that needs syncing, which database would be the best candidate today?

[mananaysiempre]

One interesting idea I’ve seen is none[1]. That’s definitely more on the exploration side than the shipping one, though.

[1] https://tonsky.me/blog/crdt-filesync/

[The_Colonel]

I can think of two complex pieces of software which intentionally shunned databases thinking they can just do its thing in "flat files" - git and DokuWiki.

What ended happening is that both developed their own custom shi*ty database engines because it turns out that things like indexes are just generally pretty useful, but doing them right is pretty damn difficult. I'm pretty sure that if Linus/git chose e.g. SQLite instead of "flat files", we'd have way fewer data corruption problems, and a more capable/extensible git.

[mananaysiempre]

I don’t know if Git’s storage is deserving of this level of scorn—I can’t lay claim to any in-depth knowledge, but if it were indeed a big problem I’d expect it to come up frequently in comparisons with Fossil, which stores things using SQLite. (As a counterpoint, I use git-annex quite a bit, and it almost certainly couldn’t integrate as neatly into Fossil’s storage approach as it does into Git’s.) So I’d appreciate any details here.

All that is beside the point, though: the article above is not about using or not using flat files as a storage primitive, it’s about using files of whatever nature as a replication and version reconciliation mechanism, in view of the fact that concurrent editing is inevitably application-specific, so we might as well lean into it instead of leaving it to a database. In that sentence, “a database” is not just any database, it’s one of a very short list of multimaster databases with relatively loose schemas, which includes CouchDB and—among legitimately FOSS projects—I’d struggle to name more.

This is not a decision about data storage at all, in other words. It is a decision about protocols. Experience shows that the alternative does not end up being an off-the-shelf database (even CouchDB, which does seem like a major road not taken looking back at Canonical’s efforts a decade ago), the alternative is usually a central synchronization server speaking a custom protocol. (CalDAV, CardDAV, Bitwarden, etc.)

And if you want to do your CRDT or OT or whatnot over per-client SQLite databases instead of per-client text files, all the more power to you.

Finally, I tried to phrase my comment above in a way that makes it clear that it’s a suggestion of a direction to have fun in, not of a principle to architect your production app around. So the sneering in your comment is... honestly disheartening to read. Like, do people even hack anymore? I know they do, but every time I read something like this I become a little bit less sure of it.

[rglullis]

hum, allow me to toot my own horn here. I've written something to that effect in 2021. https://raphael.lullis.net/thinking-heads-are-not-in-the-clo...

[bbrks]

I am (very) biased but Couchbase has a pretty solid Mobile offering for native apps. I have worked on the Sync Gateway component responsible for replication for the last six years.

Sync Gateway still maintains a CouchDB-compatible REST API, and PouchDB _mostly_ works thanks to that, but there are some corner cases and features that PouchDB does not support so YMMV with it. Our native app libraries have used a more performant websocket-based replication protocol for many, many years now, and I'd really love to have the time investigating a PouchDB adapter using this WS protocol instead.

[ergl]

I'm biased since I work on it, but https://ditto.live/ provides an SDK that allows P2P and cloud sync. You interact with it like a database: write your queries against your data, and it will move between devices automatically

[janl]

I would still recommend you give CouchDB and PouchDB a fair shot. They are used successfully by many folks.