Hi - thanks for invite. There are many NoSQL databases on offer, so perhaps the best way to approach your query is to look at CouchDB in the context of similar databases.
CouchDB is a (JSON) document store in the same class as CouchBase (which started life as a version of CouchDB combined with Membase) and MongoDB. There are other lesser known ones like RavenDB, Cloudant (another derivative of CouchDB), PouchDB, etc.
What I like about CouchBase is its http-based REST interface through which you can easily create and manage documents. The idea of a 'database for the web' that can be managed through http is interesting (even seductive) but it is worth noting that competitors like MongoDB do not entirely share this vision. If you want a 'cheap' and easy to use document store then CouchDB is great.
I'm afraid I can't find much more else to say I like about it compared to other offerings.
With CouchDB (and derivatives like CouchBase and Cloudant) you literally have a 'lake' into which to dump documents. You then have to write your own (map-reduce) processes to analyse the data. There is no query language (CouchBase have recently released a query language for their DB). Great if you have good Javascript and plenty of time.
However, coming from a relational DB background, I find the MongoDB offering far more enticing. Its data store is logically organised into databases inside which are collections (tables) The security model is familiar and strong - with the ability to secure objects based on users and roles. The query language is far superior and their aggregation framework means there is no need to create your own map-reduce functions. Adding a node to a cluster is quite easy although the learning curve increases somewhat for sharding. Replication within cluster nodes is automatic. Besides there are a good number of drivers in different languages for MongoDB.
ps: I'm not a MongoDB employee :-)
CouchDB is great. It runs on Erlang VM (great for all the new Elixir developers). It has SpiderMonkey (Mozilla's JavaScript interpreter built in). It runs everywhere where Erlang can be installed (Windows, Linux, Mac, BSD, Solaris, Raspberry Pi)
Its data model has pre-defined attributes like _id and _rev. On saving a new document _id and _rev are generated automatically. On saving a new version of an existing document, _rev is checked automatically to detect revision mismatches. You can then ask for the current remote document, compare each value and ask the user what values to keep/replace. Can it be easier for users to merge data? Replications are also relatively easy.
With PouchDB, another open source project exists which can synchronize data between mobile and CouchDB cluster. Installing PouchDB on Node.js allows all kind of imaginable crazy setups.
CouchDB talks JSON over HTTP. You can use all kind of HTTP environments like proxies, firewalls, caches, etc. to build fantastic backends. npmjs.org runs on CouchDB cluster. That brings me to another great addition, CouchApps. Because of SpiderMonkey, you can write CouchApp inside your database. Think of it like Apache and PHP are running inside of MySQL but being powered by the best fault tolerance multi concurrent virtual machine called ErlangVM.
The drawback I guess is how you define data access. You need to create design documents that contain views, shows, lists, validations, lists and filters. Each of them written in JavaScript using a particular API. But every JavaScript developer knows how to read and write API's. The technical issue here is, that you force CouchDB to spawn multiple JavaScript engines (SpiderMonkey) on each saving of design documents. Each JavaScript engine will try to take a CPU core exclusively to compile your design documents code into binary code. This isn't a big deal on smaller projects but on mid-sized projects it can cause headaches, finding performance issues. Is it an environmental issue or conceptual problem in my design document? Bringing development code to production will cause massive saving of new/updated design documents. You need to plan which node in a CouchDB cluster you need to take 'offline' by not sending any query but instead pushing your code.
Until RethinkDB, I loved CouchDB pretty much. If CouchDB 2.0 will be released this year, things may change again, but right now RethinkDB behaves a bit more like what I expect even though it's not running on ErlangVM :-P
Couchbase isn't that great in my opinion. CouchDB+Membase sounds fast but rather sooner than later you are ending up with a pricing request process because for a Sync Gateway you need to pay. That what PouchDB and CouchDB to for free needs to be paid in Couchbase. Yes indeed, it's not trivial to talk to caches (Membase) but why should I ever cache DB responses when data can change over time? Most of the time dealing with caching issues forces you to call for support but it often looks like some other kind of an issue. Also, the sales guys can be very aggressive calling after you to make you sign a contract - but that is not technical, and maybe it was/is only my experience.
To sum it up. CouchDB is great. If ErlangVM isn't a problem to have it as additional dependency then you are getting a great JSON document-oriented database. The data model is easy but the data access design can be a bit confusing. Building clusters spread across the globe or company network is relatively easy. For all kind of programming languages, clients exist (in JavaScript land: I love nano while other may choose cradle).
I'd choose couchdb for small size and you can easily use it with the Electron.
You can easily Create couchdb database in Node.JS .
When you don't want to use something like MongoDB, you can definitely use the couchdb as it is easy to scale for small projects.
I am not sure though why not most of the projects use it instead of the MongoDB. I find it pretty good enough for my use in small side projects.
Matthew Revell
Developer relations, NoSQL and more
I'd say the following are some of CouchDB's advantages:
I like the document model because it matches up with most of the real world uses I think a lot of us have. It's easy to serialise objects to JSON, store them and then retrieve and deserialise when we need them back. With a column store, like Cassandra, you'd have some of the schema inflexibility that you get with a relational database.
As a document store, rather than a pure key-value store, CouchDB also lets you index and query the contents of your documents, rather than just pulling them out wholesale. So, if indexing/querying the contents of documents is important then it'll suit you better than something like Riak.
Against MongoDB, I think the main advantage is that CouchDB is architected in a way that makes it easier to grow a cluster. I mean, this depends on your precise needs. For example, with CouchDB you can add more and more nodes relatively easily and set up replication between them. That can be great for availability but you're replicating the same full data set on each node, so it might be so great for really large data sets.
You might want to look at CouchDB's spritual descendant, Couchbase. Couchbase is also open source and was created by many of the same team. It uses hash-based partitioning and clustering, similar to Cassandra, but retains the document model. So, it's pretty much linearly scalable but lets your work with schema-unenforced JSON docs.
I'd say Couchbase has a query advantage over CouchDB too, with a SQL-like language called N1QL. You also get k/v access and CouchDB-style views.
Another advantage that Couchbase has over CouchDb is built-in managed caching, which can give you fast responses.
Overall I'd say CouchDB can be good for smallish data sets but Couchbase will give you a lot more scope for scaling and has much richer query.