CouchDB is awesome, full stop.<p>While it's missing some popularity from MongoDB and having wide adoption of things like mongoose in lots of open source CMS-type projects, it wins for the (i believe) unique take on map / reduce and writing custom javascript view functions that run on every document, letting you really customize the way you can query slice and access parts of your data...<p>Example: I'm building a document analysis app that does topic + keyword frequency vectorization of a corpus of documents, only a few thousand for now.<p>I end up with a bunch of documents that have "text": "here is my document text..." and "vector": [ array of floating point values ...].<p>What I can do with couchdb is store that 20d vector and emit integers of it as a query key:<p><pre><code> var intVectors = doc.vector.map(function(val){
return Math.floor(val)
})
emit(intVectors, 1);
</code></pre>
Then I can match an input document's vector (calculated the same as corpus documents), calculate a 'range' of those vectors, pass it as start and end keys, and super quickly get a result from the database of 'here are documents that have vectors similar to your input'...<p>Super fun, quick and flexible to work with!
One interesting thing you can do with CouchDB is that you can have a webapp where a user can specify their own database and credentials and it works over HTTP(s). That's pretty unique. I'd love to see a SaaS using CouchDB and their "on-premise" offering just means the user provides their own database. I'm not sure how payment would work though - perhaps some verification proxy?<p>Firebase is the gold-standard for offline apps (as a service). CouchDB replaces Cloud Firestore, and Keycloak replaces Authentication. I haven't seen OSS equivalents of Cloud Functions, ML Kit, and the other things (e.g. In-App messaging, and Cloud Messaging). It'd be nice to have the entire stack of Firebase bundled as a group of OSS projects, including CouchDB.<p>Sad to see that per doc access control didn't make it in 3.0. Hopefully it'll be in 3.1.
I built two products on CouchDB 1.x starting in 2010 ... version three is another amazing step forward! For my more recent projects, I've replaced CouchDB with clustered PostgreSQL using JSON columns as I really enjoy the ability to write SQL queries for against the JSON and to use the built-in full-text search capabilities. I think both CouchDB and clustered PostgreSQL are amazing tools and it's nice to be able to choose between them as needed. The best advice I've heard is to choose CouchDB when you know your queries ahead of time and the data "schema"[1] is variable and choose PostgreSQL when you know your data ahead of time and your queries are variable.<p>[1] In this case, a JSON document but either with a JSON-schema or marshaled/unmarshaled into a strict type.
CouchDB is awesome and feels way ahead of its time. Its design docs are extremely powerful, to the point that you can build entire web apps with CouchDB alone (not that that's recommended anymore). Plus with PouchDB you can create offline-first apps that sync with a remote CouchDB instance.
I haven't heard of CouchDB in quite some time, great to see it still improving.<p>I used it years ago when I was experimenting with Ionic[0]. What appealed to me was that I could use CouchDB (cloud) and PouchDB[1] (device) to and have a replicated copy of the data locally. The application was used in areas where network connection was very limited. Using this strategy I was able to ensure the mobile devices data was as recent as the last time it had a network connection.<p>[0] - <a href="https://ionicframework.com/" rel="nofollow">https://ionicframework.com/</a><p>[1] - <a href="https://pouchdb.com/" rel="nofollow">https://pouchdb.com/</a>
Reducing max document size from 4GB down to 8MB seems hyper-restrictive.<p>For those interested, looks like the guts of CouchDB are going to be swapped out for FoundationDB.<p><a href="https://blog.couchdb.org/2020/02/26/the-road-to-couchdb-3-0-prepare-for-4-0/" rel="nofollow">https://blog.couchdb.org/2020/02/26/the-road-to-couchdb-3-0-...</a>
> – Updated to modern JavaScript engine SpiderMonkey 60<p>Yes ^^ !<p>Congrats to the team. These people are some of the nicest and most supportive devs I know of in the OSS community (or whatev').<p>They show a great deal of patience in their slack channel and are always welcoming and answering stupid questions from idiots like me.
At this point why would you use CouchDB over something like MongoDB?<p>Seriously asking...<p>Over the past 5 years MongoDB has gotten a great storage engine, transactions, distributed transactions, multi master replication, first class change streams and is very very solid as a foundational piece of infrastructure you can rely on while CouchDB has languished. I can’t imagine reaching for it in my tool belt when I need a document store over MongoDB but I’m obviously biased so I’m wondering if there is a lot I’m missing.<p>Obviously it’s cool from a more open source databases standpoint — I love learning about how things are built and evolve over time.
Has anyone here tried to use couchdb <i></i>directly<i></i> within an elixir/erlang OTP application? As like, „mix install“? Would kill for couchdb as a library!
Other than being a great solution for some problems I wanted to highlight the fact that CouchDB has commited to SpiderMonkey (the Mozilla JS engine) since the very beginning and is one of the few projects helping to fend away the V8 monoculture.
Oh wow, this is great news. I though the project was effectively long dead. Is there a new/up-to-date "couchapp" too?<p>> Default installations are now secure and locked down.<p>More good news!<p>Anyone have recent experience with couchdb?<p>I see the (quickstart) docs use plain http - should one terminate ssl in front, eg with a recent version of haproxy?
I'm surprised to see so much love for CouchDB in this thread. I don't think it's been widely adopted in corporate america and has lost the war to MongoDB closed source or not.<p>I joined a company where it's being used backing a mobile app with couch/pouch in production. We can't wait to get off of it. Writes are slow. Reads are worse. Having a DB per user is a scaling and backup nightmare. If you run into any issues, it's a ghost town.<p>I'm glad the CouchDB Team is forging ahead, but who is really using this database?
CouchDB/PouchDB looks very promising for offline first apps, but I can’t understand how to restrict bad clients. Client potentially could insert document of huge size or execute expensive query and degrade experience of other clients on the same server. Is it any way to prevent this?
Many commenters here still think CouchDB is the same thing it was many years ago.<p>CouchDB was a simple but very powerful idea (that still needed improvements), but it was coopted into something not very nice nor good nor useful.<p>See my old rant about it and why it failed: <a href="http://web.archive.org/web/20170530122143/http://entulho.fiatjaf.alhur.es/notes/about-couchdb/" rel="nofollow">http://web.archive.org/web/20170530122143/http://entulho.fia...</a>
is the lucene search indexer synchronous with couchdb days updates?<p>I'm wondering how people solve the common search after create pattern when using external indexes
I once read that the right way to use CouchDB is for every user to have its own database. However, how does this work with BI? Or with public data that should be known by all users? Do I create a single centralized DB just for that kind of data? Maybe aggregate data from all users' DBs? Genuinely curious.
I haven't used CouchDB in years. I just downloaded and installed it. Interesting that there are no apparent links to client libraries in different languages. Perhaps most people just use the HTTP API Reference and roll their own.
CouchDB is good. Yes. I still dream of the day when the cluster will balance shards automatically and recover better from losing and replacing nodes. :D
Maybe I'm being petty, but it doesn't fill me with confidence when the ssl certificate on their website isn't even configured properly (valid for uberspace.de domain).<p>To clarify: seems their main site is on apache.org. But, their www.couchdb.org site (hosted on uberspace.de) doesn't have a correct cert.