What is your take on CouchDB? After some initial investigation, I've all but written off CouchDB for anything moderately write-heavy due to its single writer at a time design. I'm by no means an expert on that however. Please tell me what I'm missing about CouchDB.

I tested various NoSQL solutions including CouchDB for my research work. It was the most pleasurable to work with, but by far the slowest. Bulk inserts weren't an option for me, so I had to insert each document one at a time. Insertion time averaged at ~2.5 seconds(!) These documents were very small, and the insert operations were single-threaded, so the write lock wasn't an issue. Compare this with ~150 microseconds on the datastore I implemented instead, or (from what I remember) even better performance on Tokyo Tyrant.

I used CouchDBX on a MacBook laptop with no adjusted settings. Something must have been off, but after reading so many articles talking about how alpha the product was and hitting these insane performance limitations, I wasn't willing to venture any further in experimenting with it.

Take a look at this also: http://news.ycombinator.com/item?id=942810

CouchDB is conceptually promising (especially when combined with HTML5 - that's an awesome solution waiting to happen) but its performance is crippling IMO. I can't wait until the team starts focusing on performance tuning. Perhaps then we'll see a very practical and useful datastore.

If I recall Damien Katz recently added a "many writers" patch.

Yep, Damien's patch greatly improved CouchDB's write throughput for the case where you've got a pool of processes trying to write to the same DB simultaneously.

I have a beta account but I have not yet used it very much because I have CouchDB running on two of my own servers, and usually on my laptop.

Except for not really being able to do ad-hoc queries (you write map/reduce view functions which create indices) I like CouchDB. That said, I use MongoDB a little more frequently because it is easier for me to use.

What I really like about CouchDB is the way it uses REST and JSON. I use Ruby clients, and sometimes I prefer to just use simplehttp and json gems, and do everything low level because it feels natural.

I think a good way to promote this would be to self-host the blog using a CouchDB application running on Cloudant instead of using Posterous.

I disagree. I would only even consider using a schemaless DB in a case where I need high performance logging of unstructured data. We use it at work as a hot cache and as first line click & impression tracking.

I wouldn't be remotely impressed that it could serve a blog. It would be meaningless to me.

I'm wondering what differentiates this service from http://hosting.couch.io/. Is it about extra GUI management options? Both seem very interesting services, because as an existing CouchDB user I can absolutely see the benefit of having an external database to replicate to.

I've used both hosting.couch.io and Cloudant. So far I've had the best experience with Cloudant.

hosting.couch.io seems well geared for playing with CouchDB and building pure CouchDB apps. There is clearly a great team behind it but they seemed to be working on and distracted by a whole bunch of other things rather than focusing on making the hosting service brilliant.

Cloudant feels like a more robust service that will scale as usage of my app grows. They also have a great team but appear to be much more focused on delivering the best hosted CouchDB service. They also have a number of funded startups that are dependant on them which gives me more confidence that they are taking the service seriously.

(full disclosure, I'm a founder at Cloudant)

Thanks for the kind words jot. The guys behind couch.io are smart and talented, and they really know their couchdb, but I don't think that hosting is their primary focus (they can correct me if I'm wrong).

The main technical difference between us and couch.io is the distribution (clustering) layer we've built. This allows a single couch database to be spread across multiple servers. It provides true horizontal scalability, not just multi-master replication. A database can expand elastically based on resource and concurrency needs. In our next release we'll be adding the ability to tune robustness via quorum constants (a la Amazon's dynamo) on a per-document basis. That should be coming soon.

They also have a pretty impressive team: http://cloudant.com/#about

If you look at the source, you can see about 500-1000 words that aren't displayed on the page / doesn't sit well with my "good intentions" meter.

I think that's because steadicat built the site as a single page. The words you're talking about are anchored at #faq, #terms, etc. right?

It's not ajax, it's javascript and css. All the content is on a single page.

Good point. I kind off broadly classify all javascript only pages as Ajax though its not strictly. I guess with one page only it was probably easier to make the website.