About CouchDB
In this talk from 2009, Michael Miller highlights some of the core features of CouchDB, those that would make it appeal to the developer public:
- Bi-directional incremental replication
- Custom views built with Javascript functions and saved to disk
- Filtered replication, so users can get part of the data
- Couchapps: lightweight web apps served directly from the database
What is the state of these awesome features today, 2016?
The replication protocol, which supports multi-master, has changed little, and has received criticism, but, as it is, it is the only open replication protocol out there, the only one that stands the fight, and the only one people were able to implement in the browser. PouchDB is probably the main reason people adopt CouchDB today. There are other things that talk that same replication protocol, so that’s a thing.
Continuous replication, however, is too heavy, uses too much memory, and I don’t think the idea of keeping two or more CouchDB databases in continuous replication today is good as it sounded back then.
Custom views always seemed to me as a gift from heavens, the solution to the dilemma between normalization and data duplication, they should be fast and flexible and support any use-case. That’s how it sounds in that Miller presentation. However, today most CouchDB seem to be approaching views as just a confusing complicated hard way to do simple queries, like getting a list of items by the name of the category they’re in, and other boring queries you can imagine.
This whole problem gave rise to the Cloudant Query Language and pouchdb-find. The second advertises itself as “inspired by MongoDB, it provides a simple API with operators like $gt (greater-than) and $eq (equals), so you can write less code to achieve the same performance as the map/reduce API”. In other words: everybody seem to be looking at CouchDB as just a very poor and limited MongoDB.
To be fair, that is in fact the only sane way to approach CouchDB views, as other approaches, like the monolithic, cannot be used with a lot of data, and you must be sure your blocks of data will not get too big if you’re willing to put them in massive documents.
Filtered replication was implemented, but it is slow to the point that no one recommends that you use them. I imagine the original idea was to mix filtered replication with Couchapps to make full-featured applications that the users would run on their own CouchDB instances, syncing back and forth from centralized CouchDB instances.
This idea would have been even more powerful if done with PouchDB on the user side – since, I guess, no one has ever succeeded in distributing a CouchDB application to end users that ran their own CouchDB –, however the inefficiency of filtered replication made all these dreams come apart.
From the ruins of filtered replication emerged the db-per-user idea, which is the same filtered replication, but in such a way that a user owns the entire database and controls a PouchDB instance that replicates to and from that centralized database. The server may do things with the data stored in the CouchDB under its control, but the user at the same time has a copy of the entire data and it supposedly can work with it offline. This is a great idea, but if we look closely, it is much more limited than the original vision.
About Couchapps, the special database features that powered them in the first place were left aside as offline-first database-per-user PouchDB apps started to gain hearts and minds, and on the other side apps that would rely on a single server started to require features, like sophisticated authorization and per-document access control, that could only be provided by putting a normal server in front of CouchDB.
Like what happened to views, this is a sad thing. By trying to do things in the “regular” way, CouchDB users ignored CouchDB innovative ideas and made it look like a limited weird piece of software that lacks so many features that you must write a ton of middleware (that, of course, cannot be run inside CouchDB, what a limited server it is) to make it do simple stuff.
I must say, before it is too late, that I’m not in the big enterprise game, so I don’t know how (if any) enormous software companies are using CouchDB and how it is working for them, this is just my impression from the low end of things.