This is a huge release. Replicator was effectively re-written, much faster internals, HTTPS support is native. These features are warmly welcomed! Excited to see this now integrated into BigCouch!

In the older (v0.9) docs they recommended pull replications over push . Is this still the case? (http://wiki.apache.org/couchdb/Replication)

We would like to push support related data from a customer db (inaccessible from the outside) into an external server.

The new replicator isnt in the 1.1 release, it is in trunk and likely to be in the next release

This is not true. read the release notes.

What Dale said is true. The replicator database and the replicator itself are 2 different entities.

I wish CouchDB would implement internal compaction. I'd love to use CouchDB and Elastic Search with the CouchDB River plugin. This would give me a nice REST infrastructure with a schemaless store (couchDB) and the ability to do complex queries in real time (elastic search).

Sadly my data is too write/update-heavy and just keeps on growing and growing. This means that I'll have to use compaction if I don't want to run out of space sooner or later. Starting compaction will kill performance over several hours and depending on the amount of written data might not even be able to finish :(

We are working on auto compaction. The Couchbase alpha already supports it. This should help, but it will help even more on a cluster as each shard can be compacted independently.

does "auto compaction" mean that the compaction process is just automatically triggered?

Yes, but only when certain configurable conditions are met (fragmentation level, time period). There's some user level documentation in the default.ini config file:

https://github.com/couchbase/couchdb/blob/preview/etc/couchd...

ok, that would still lead to a situation where my server crawls to a halt for hours and might never finish if I don't basically take it offline :(

Can someone explain what's so important about this release?

Here are some:

* Added _replicator database to manage replications.

It used to be that if a continuous replication was launched but the server was re-started that replication task was lost. Now it will continue where it left off.

* Added support for HTTP range requests for attachments.

Just looking at the unit-test for this commit, you can apparently specify a range of bytes out of an attachment and fetch only that.

    var xhr = CouchDB.request("GET", "/test_suite_db/bin_doc/foo.txt", {
 	headers: {"Range": "bytes=10-15"}
 	}); 

* Added stale=update_after query option that triggers a view update after returning a stale=ok response.

Before, if stale=ok was passed to a view then you'd just get back stale view data and (I am guessing) a view update wasn't triggered. Normally a view update is triggerred the frist time the view is accessed after documents have been updated. However that could take a while for the views to regenerate. Now with stale=update, stale data is returned but an view update is _also_ triggerred in the background.

* Added configuration option for TCP_NODELAY aka “Nagle”.

Should help for situations where you'd want to trade some throughput for latency. Your packets will be sent out sooner, they will be smaller, but there will probably be lots more of them. See here for more :

  http://en.wikipedia.org/wiki/Nagle%27s_algorithm

The biggies I've been personally waiting to see land in this release are:

* Added OS Process module to manage daemons outside of CouchDB.

* Added HTTP Proxy handler for more scalable externals.

What these effectively mean is that you can write CouchDB handlers in the language of your choice as long as they speak http. You can get the full details from the author of the above patches here:

http://davispj.com/2010/09/26/new-couchdb-externals-api.html

This makes possible things like LivelyCouch, integrating node.js with Couch:

http://www.livelycouch.org/

I didn't know about livelycouch. It seems to be a great idea. Thanks for mentioning it.

A bunch of the other changes are about making CouchDB more suitable as a public-facing web server, hence the SSL support & improved ETag support for example.

The CouchBase version has been at 1.1.0 for a while (since March 24):

http://www.couchbase.org/wiki/display/membase/Releases

Does anyone know if theirs was an early release of 1.1? Or are their version numbers out of sync with the Apache versions?

Couchbase releases are not in sync with CouchDB releases, the Couchbase server is based on CouchDB 1.0.1, the reason their versions arent aligned as Couchbase releases are not Apache CouchDB releases

I've been using the CouchBase release since before they became CouchBase. I haven't closely followed the whole CouchOne/Membase merger. Is there any reason to switch to the official Apache release?

I use CouchDB as its easier to track development, the Couchbase builds are more convenient if you dont have strict version requirements and dont build from source (they have geocouch included and nice packaging for osx).

Thanks Dale, this is good to know. Any plans to update Couchbase server to be based on CouchDB 1.1? I know the _replicator DB would be a particularly nice feature to have.

I've been using the Couchbase server alpha for a good while for a few reasons. _replicator DB has made a lot of things a lot easier for me. I get a pretty good reduction in file space as well (my wikipedia database is about 25% smaller, for example).

So far, there are only mac builds (because I'm building them and that's what I'm deploying on), but Linux should come shortly and we should stop calling it alpha.

If you've got a mac and want to try out some new stuff, do this and complain to me about anything you don't like: https://gist.github.com/951106

The next major version of Couchbase will have that feature, amongst many others (the alpha release already has it in fact).