4 ms·
I’d like to repeat my comment from another recent thread: I mostly used MySQL. But for my app, I now use CouchDB. It has its limitations, but the automatic syn
by WA 8y ago
I’d like to repeat my comment from another recent thread:
I mostly used MySQL. But for my app, I now use CouchDB. It has its limitations, but the automatic sync between devices is pure gold. I haven't written a single line of sync code and it just works.
It baffles me a bit that CouchDB isn't more popular and that people rather use MongoDB for NoSQL, which doesn't come with the same syncing capabilities.
Adding to this: if you want sync out of the box and like NoSQL (and your app isn’t super complicated), CouchDB is clearly better than Postgres (and Mongo of course).
- brightball 8y agoSync is the primary use case for CouchDB (and PouchDB). It really deserves more attention for that IMO. It's not ideal for a lot of other use cases, but where it fits it shines.
- WA 8y agoI just wonder if there is a single reason why anyone would use MongoDB over CouchDB/PouchDB.
- brightball 8y agoIf you remember when Mongo first came out, it made a splash with a lot of write focused benchmarks. They were achieved by RAM buffering the writes and then persisting to the disk periodically. Couch never led in benchmarks and always focused on consistency or both performance and data. That’s not as flashy with the “OMG Benchmarks!” crowd, in my experience at least. Couch operates entirely over REST last time I checked as well, which makes it a bit clunky for a lot of use cases. Couchbase attempts to be the fast version of Couch and seems to do pretty well.
- anthony_barker 8y agomy only two issues with couchdb are the query language has some learning curve and it would be nice if they had good support for public/private key authentication like lotus notes had.
- ravenstine 8y agoI'm sure that could be done using Proxy Authentication? Either way, you should suggest that feature on their Github.
- brockers 8y agoI have to second this. CouchDB has a much better native interface than Mongo (pure HTTP/REST JSON) and automatic syncying. Honestly, most of the time I think the real problem is developers not being able to cognitively handle changing from a SQL style declarative syntax to a functional map/reduce style syntax. It takes higher-order thinking, but the results are dramatically better.
- Maro 8y agoSQL is declarative. There's no sense in which functional is higher-order than declarative. When you write map/reduce, you're doing a mix of functional and probably imperative down the line. Putting syntactic sugar aside, it's hard to beat SQL in tersity, because you're talking to a big query engine which can do JOIN/WHERE/GROUP BY/HAVING/etc.
- ravenstine 8y agoI'm so glad to hear from another person who appreciates CouchDB. I think people choose MongoDB because big data performance isn't a selling point with CouchDB, but it's feature rich and my go-to database when staring new projects from scratch. For those unfamiliar, here are the cons and pros of CouchDB. CONS: - Not as performant as MongoDB, but still pretty fast for most purposes. - Probably won't ever have transactions. -No direct socket connection or native driver; its protocol is entirely dependent on HTTP. PROS: - Has a REST-like HTTP API. - Admin interface out of the box. (aka Fauxton) - Replication is dead simple, and probably the biggest killer feature. - Is a gateway drug to PouchDB, a JavaScript implementation and client for CouchDB. - Comes with a changes API out of the box with support of long polling, server sent events, and web sockets. (basically so an app can live update documents) - JSON documents support file attachments, just like Email.
- ghop02 8y agoSyncing smaller databases between devices seems to be the best use case of CouchDB. However, Couch is extremely difficult to manage at scale, especially when managing indexes on top of documents. The index generation was extremely slow and wasn't able to take advantage of beefier hardware at all. Deploying updates to indexes had to be done extremely carefully as it will rebuild the entire index and lock reads from that index in the meantime. Iterating through GB of documents takes a wildly long amount of time, especially if other operations such as indexing updates are happening. Furthermore it had scary failure modes. There were many times that a couch instance would die with documents cached in memory but not yet written to disk, even though couch had returned a successful document write. We found that documents we thought existed were lost forever during this blip.