4 ms·

I remember CouchDB when it was initially released, it was one of the most promising and innovative DB's around. It's a shame it didn't live up to the hype.

ohstopitu 10y ago
why do you feel that it didn't? (genuinely curious) I used it for a variety of projects and seem to love it.
qwertyuiop924 10y ago
I actually quite like Couch. It's an interesting system, and I think it doesn't get enough credit.
rdtsc 10y ago
> , it was one of the most promising and innovative DB's around. It's a shame it didn't live up to the hype. It promised master-to-master replication, so has that. Doesn't lose your data (actually fsyncs, yay!). Has a helpful integrated web interface, is HTTP + JSON interface. I don't know I've shipped lots of products on it. I say it lived up pretty well to the hype...
fet 10y ago
Hype or not, I inherited a project that had CouchDB baked into the bones. While I found its disk space usage and its time to reindex large databases frustrating, I did appreciate REST-like queries, how it just saved whatever you wanted and how the map/reduce queries could actually be quite powerful for ETL and reporting (though it took a good while to index every time we had a change). We abandoned replication early on as just too chatty over high latency networks. I love the CouchApp idea because it's a natural extension of "save whatever you want." As long as we're saving json, why not save static files too? It lets you prototype quickly and, in our case, let us develop and test out specific features for clients by quarantining risky crap code on the fly into one database. I like to think we're beyond that stage, but at the time it was invaluable to keep multiple versions of our app running concurrently. I have 3 solid years of experience working with CouchDB and in the end I find myself longing for PostgreSQL with one bson column for the unknown or "volatile" attributes. Our data was semi-relational, as I would argue is most data. Meaning there were honest to goodness has-many or belongs-to type queries that could have been simplified and easier to maintain outside the application code. I know that's just a style, some people would use key-value stores for everything with no validation on anything. If you're not that far gone and you still like freedom then CouchDB might be for you. As for me, I wanted an error from my database if my application code asked for something or tried to store something invalid. But for rapid prototyping for us I don't think we could have gotten a better database.
- rakoo 10y ago
  > As for me, I wanted an error from my database if my application code asked for something or tried to store something invalid It is not enough for actually relational data, but surely you know that CouchDB has validate_doc_updates functions specifically designed to check user rights and document structure ? http://docs.couchdb.org/en/1.6.1/couchapp/ddocs.html#validate-document-update-functions http://docs.couchdb.org/en/1.6.1/couchapp/ddocs.html#validat...
patwolf 10y ago
I wouldn't say that it didn't live up to the hype. I think it just has a steeper learning curve than a lot of other NoSQL databases and is often overlooked. MongoDB makes a lot of sense to folks already familiar with relational databases. Collections are like tables, documents are like rows, and it's easy to use document IDs to establish relations and perform queries like you would in a relational database. There are a lot of problems with using it like a RDBMS, but still a developer with zero knowledge of MongoDB can become productive with it very quickly. When learning CouchDB, the first WTF moment is when you realize there are no tables and that all the documents regardless of the type of data they contain go in the same place. Eventually you learn that you can add a type field to the documents to distinguish between them, which does feel hackish. The next WTF moment is when you want to query the data and realize you have to use map-reduce to do what would seem trivial in any other database. The early version of the admin tool definitely didn't make this easy since it required writing a JavaScript function and escaping it so that it could be stored as a single-line JSON string. It also didn't help that the map-reduce code was stored in special documents that used magical document IDs to distinguish them from other documents, which again feels hackish but makes sense eventually. That said, I am a big fan of CouchDB, and I hope that with the query language and new UI in 2.0 that CouchDB will earn the respect it deserves.
- desireco42 10y ago
  Yeah MongoDB kind of dumbed down whole 'rethinking db' attempt. Compared to how much attention and developers others much simpler db's got, CouchDB definitely didn't get as much as it should and could. I am looking forward to see new features for sure.

ohstopitu 10y ago

why do you feel that it didn't? (genuinely curious) I used it for a variety of projects and seem to love it.

qwertyuiop924 10y ago

I actually quite like Couch. It's an interesting system, and I think it doesn't get enough credit.

rdtsc 10y ago

> , it was one of the most promising and innovative DB's around. It's a shame it didn't live up to the hype. It promised master-to-master replication, so has that. Doesn't lose your data (actually fsyncs, yay!). Has a helpful integrated web interface, is HTTP + JSON interface. I don't know I've shipped lots of products on it. I say it lived up pretty well to the hype...

fet 10y ago

Hype or not, I inherited a project that had CouchDB baked into the bones. While I found its disk space usage and its time to reindex large databases frustrating, I did appreciate REST-like queries, how it just saved whatever you wanted and how the map/reduce queries could actually be quite powerful for ETL and reporting (though it took a good while to index every time we had a change). We abandoned replication early on as just too chatty over high latency networks. I love the CouchApp idea because it's a natural extension of "save whatever you want." As long as we're saving json, why not save static files too? It lets you prototype quickly and, in our case, let us develop and test out specific features for clients by quarantining risky crap code on the fly into one database. I like to think we're beyond that stage, but at the time it was invaluable to keep multiple versions of our app running concurrently. I have 3 solid years of experience working with CouchDB and in the end I find myself longing for PostgreSQL with one bson column for the unknown or "volatile" attributes. Our data was semi-relational, as I would argue is most data. Meaning there were honest to goodness has-many or belongs-to type queries that could have been simplified and easier to maintain outside the application code. I know that's just a style, some people would use key-value stores for everything with no validation on anything. If you're not that far gone and you still like freedom then CouchDB might be for you. As for me, I wanted an error from my database if my application code asked for something or tried to store something invalid. But for rapid prototyping for us I don't think we could have gotten a better database.

rakoo 10y ago
> As for me, I wanted an error from my database if my application code asked for something or tried to store something invalid It is not enough for actually relational data, but surely you know that CouchDB has validate_doc_updates functions specifically designed to check user rights and document structure ? http://docs.couchdb.org/en/1.6.1/couchapp/ddocs.html#validate-document-update-functions http://docs.couchdb.org/en/1.6.1/couchapp/ddocs.html#validat...

patwolf 10y ago

I wouldn't say that it didn't live up to the hype. I think it just has a steeper learning curve than a lot of other NoSQL databases and is often overlooked. MongoDB makes a lot of sense to folks already familiar with relational databases. Collections are like tables, documents are like rows, and it's easy to use document IDs to establish relations and perform queries like you would in a relational database. There are a lot of problems with using it like a RDBMS, but still a developer with zero knowledge of MongoDB can become productive with it very quickly. When learning CouchDB, the first WTF moment is when you realize there are no tables and that all the documents regardless of the type of data they contain go in the same place. Eventually you learn that you can add a type field to the documents to distinguish between them, which does feel hackish. The next WTF moment is when you want to query the data and realize you have to use map-reduce to do what would seem trivial in any other database. The early version of the admin tool definitely didn't make this easy since it required writing a JavaScript function and escaping it so that it could be stored as a single-line JSON string. It also didn't help that the map-reduce code was stored in special documents that used magical document IDs to distinguish them from other documents, which again feels hackish but makes sense eventually. That said, I am a big fan of CouchDB, and I hope that with the query language and new UI in 2.0 that CouchDB will earn the respect it deserves.

desireco42 10y ago
Yeah MongoDB kind of dumbed down whole 'rethinking db' attempt. Compared to how much attention and developers others much simpler db's got, CouchDB definitely didn't get as much as it should and could. I am looking forward to see new features for sure.