People behind it are really, really nice though.
One of the top (the top I think ?) obsidian sync plugin uses it.
It's an offline first PWA (Salesman need to make an order even if offline).
And pouchdb make it easier because we don't have to care about indexeddb, leveldb or whatever of users browser's db.
So its a single codebase for serving web, ios and android.
Its great for sync but less then good for other uses
I was naive when I chose it (I was just starting to program then), but it has served me well. It's replication feature is simple to setup and is robust. It uses a REST API for any calls to the database, and it is a well designed API. I don't use all its features, but I really like it for the ones I use.
Unfortunately I think the answer was nobody would use it.
CouchDB is a document database that can be essentially indefinitely clustered to grow and shrink with your application / traffic demands.
It also comes with a unique replication protocol that allows you to synchronise casually connected instances (say offices around the world, or mobile devices and a cloud) much more like git uses push & pull. No other database really puts that into an open source / open government project.
There’s tons more cool stuff that CouchDB does and its being used in mission critical infrastructure that you’re relying on every day :)
If you could share a bit on those I think the community would be extremely interested. There was that CERN thing a decade ago, if it's still true or there are other actors with similar amounts of data, there would be fewer comments about not finding CouchDB useful
That single featurte right there was why i first had started playing with couchDB several years ago. It really had been quite awesome! I think other features that help it really help with offline-first approaches also are really cool! But, ultimately, after playing with it (and really liking it), i just didn't have a need for too many personal use-cases....since sqlite was "good enough". I thought - and still believe - that for wider (maybe corporate/enterprise?) uses, it can still fit the need....but i don;t hear much buzzz about it in general...so in my case, i stopped using it, and forgot about it. Apologies to any devs behind it, no offnese meant...i just got my personal use-cases covered by sqlite...and on enterprise side, too many internal politics to convince stakeholders that couchdb would be better than other solutions in some use cases.
Also, the documentation back in the day to get started was ok-ish, but there didn't seem to be much around....i guess it could be one of those things where it is/was a great thing...but if not enough attention and use exists, then it won;t trigger a wider audience of devs who will also document more stuff and further triugger a virtuous cycle?
Anyway, good to see the devs are still at it! :-)
The real shame is that Map/Reduce is simply a toy, easy-to-add bonus when looking at the data structure, but that's not what CouchDB is or ever was about. The one reason it was created is replication and simplistic conflict handling, and it does it perfectly.
The reason CouchDB never took off is that it targets offline-first, something you'll see associated with peer-to-peer systems, but does that only for servers: you're supposed to install that thing through packages, configure a text file, run it with your preferred daemon manager, ... If CouchDB had a simple desktop version you could start in one click and forget about, it would have been way more interesting. Alas.
> Optionally replace md5 with xxHash for data integrity checksums. 30% speed up on larger (128k) docs, no difference for smaller docs.
Happy to see xxHash getting more and more popular!
> In that case, upgrade to 3.4.0 without changing the default and enable xxHash in 3.5.0 or later so you can roll back to 3.4.0 then.
This should probably say 3.4.1, not 3.4.0, in the two places in that sentence where it says 3.4.0. Right?
