- Sync is best in class for NoSQL databases
- PouchDB is still one of the best JS libraries for NoSQL local storage
Cons:
- Confusing subtle incompatibilities between versions (CouchDB 1.x, 2.x, and 3.x break compatibility on various things, naturally, but also things like Couchbase is CouchDB compatible until it is not; Cloudant is CouchDB except in the areas where it isn't)
- Attachments don't sync well for a high level feature
- Managed/auto-scaling providers are slim-pickings and growing worse: Cloudant is IBM Cloud only now; Couchbase's pricing model is confusing and their business model seems to shift often enough I don't understand what they are doing at any given moment in time (and Couchbase isn't CouchDB and has a suite of incompatibilities)
My status:
- I've had to move everything that had been using Attachments to using a custom storage sync solution.
- I've been looking at building some sort of Proxy to do PouchDB sync to Azure CosmosDB because we've got Azure hosting requirements and PouchDB offline support needs to stay, but we need to rid of Cloudant and we don't want to manage Apache CouchDB servers by hand. Or some sort of replacement for PouchDB that is half as nice.
- It does what it says, a document database with multi-primary/master nodes, which is good and rare.
- It has been relatively reliable over the years for my previous company, while running on very "beta" managed Azure AKS cluster. CouchDB has been the most reliable component of the stack, together with RabbitMQ (both are using Erlang but it may be coincidence).
- The community is not huge but friendly and helpful. Once a coworker corrupted a test database (it involved network volumes on AKS on Azure), and the community helped me retrieving most of the data because some people put important data in a test database.
- It improves slowly but surely over the years. The background indexing has been a huge improvement for example.
Cons:
- It's not very fast, especially on VMs with network volumes.
- Indexing takes a while, so migrations can take a very long time when you transfer the data.
- The indexes uses a lot of ram, by design.
- The community is small, so sometimes you have to send a pull-request or two.
- Complex queries is not its strong side. The query optimiser will default to a large scan in most cases if you are not careful to use your indexes correctly.
- When you have an issue or a question, not many people got it before you.
I left the company but last time I talked with the CTO, they were happy with CouchDB and they didn't want to migrate to something else. But I think the requirements (resilient multi-primary document database) where not necessary after all, and the company would most likely use PostGreSQL if they had to redo everything now that they know the actual requirements (a database with relations, transactions, fast complex queries, and a failover is enough).
- Your documents are kept with revisions instead of overwriting then.
- REST API already built in
- Authentication (also usable in your app) already built in
- map/reduce
- CouchApps
CONs:
- corporate supported development is dwindeling (I believe, not entirely up to date on this)
- only REST API, no wire protocol
- CouchApps
I wouldn't store my main app database in there, I would use postgres (with django most probably) for that.
I would use it to store meta data, that makes more sense in json format and that has fairly simple querying needs (no complex or flexible joins, sums, etc).
We had terrible experience with mongodb (very early version) even with 100k docs.
Cons: - Large disk space required for indexes - Indexing is somewhat slow
Go with “smaller” document ids, you can thank me later.
What size would you recommend? UUID is 16 bytes?
> you can thank me later.
Thank you! :)
The thing is, document ids are used for indexing. So taking a simple eCommerce store as an example (assuming you have 100s of thousands of products) Product.id will be used extensively in indexes, you would want products to be displayed in a particular order, categorize them, sort/filter by price/listing date etc and so on. Which means lots of map-reduce views (which create these indexes). So you would want product ids to be as small as possible.
Seller.id, Review.id won't be used as extensively, you can then go for UUIDs.
But Ids can be used creatively for filtering or sorting `prod-{yyyy-mm-dd}-iphone13`, if that's your use case, you should forget about the id length. Id length matters mostly for disk usage in indexes.