If CouchDB works for you today, there is no reason to drop it. However, I'm working hard to make sure Couchbase works even better for you. That's what I'm saying.
CouchDB works and I like its API. I understand that performance could be better. But that is all.
It would have been really exciting for example to add:
* Support for msgpack or protobuf protocol to insert docs
* Rewrite core components in C, but keep the external API the same.
* Websocket changes feed
* An option for an in-memory only db version
I not sure I necessarily want more of membase-type DB. What I like about CouchDB:
Won't turning more towards a fast key-value store mean competing with Riak & Redis? Both are already established products that do that. I use Redis for example for temporary fast, in-memory key values.
So I guess my question is what would make Couchbase Stand stand out and want someone move to it compared to the existing key-value dbs? I think it is imperative for Couchbase Server team to make that stand out. A short bullet point list will do.
Another issue I see is, ok, let's say you I see Couchbase Server as an evolution of CouchDB, is there a way to replicate from one to another, is there way to smooth the transition (install both products have a replication set up and slowly move code to use Couchbase Server).
In the end I understand that developers have to eat too and that projects and people have to move on. It is a Darwinian competition and sometimes projects just lose, sometimes it is luck or timing, sometime they are misunderstood, and it is just marketing.
memcached (binary) protocol for both doc manipulation and "changes" helps performance considerably. We looked at inventing a new protocol to stream stuff in and out faster, but we decided to go with the one we already had. Though the internal APIs have been shifting a bit, it was built entirely without touching the couchdb core and gave us a huge performance benefit over http: https://github.com/couchbase/mccouch
rewriting (not core, but slow) components in C is always the right way to do this sort of thing. We've been in the process of building a NIF for document updates for a while now (TBH, I don't know where the source is off the top of my head, but we don't keep stuff closed). We've got massive performance gains in pure erlang, but we expect to cut CPU consumption down more with this new code. It's intended to be available to Apache CouchDB if they want it.
I like CouchDB a lot myself, and use it for lots of projects (including critical parts of couchbase, inc.). If we can't solve the same problems with the new product, we'll know it because we use it ourselves.
One of the claimed reasons to move to Couchbase Server is supposedly because CouchDB has performance issues.
So parts of Couchdbase will be written in C/C++ for performance. So my point was why not try to improve the performance of CouchDB by writing performance critical parts in C, keep the existing API, possibly add a new telnet like interface with protobufs instead of completely moving to something else?
It is like they threw away the best parts of CouchDB and started to compete with Riak and Redis. That is why I really want to know the list of features that will make Couchbase Server better than those two products. Since those 2 are stable and Couchbase Server is still in beta, I know which one I am not choosing for a key-value store.
The new Couchbase Server is based on Membase (it adds JSON documents and incremental Map Reduce). Most of critical code is already in production today on lots of very big sites: http://www.couchbase.com/customers
So when Couchbase Server 2.0 comes out of beta, we'll mean it. The developer previews we've been releasing are as solid as some open source projects ever get, and yet we are still putting a full QA team on torturing it before we'll call it ready.
> The new Couchbase Server is based on Membase (it adds JSON documents and incremental Map Reduce).
That is good news. I will look into it some more.
What would really be helpful is to have a bullet point comparison of features between Apache CouchDB and Couchbase as well as between Couchbase and Riak ,Redis, MongoDB, Membase. Basically an updated and extended :
As I understand your post, CouchDB and CouchBase are both NoSQL document stores, but CouchBase is designed to be more scalable with a better defined support. I think this is fantastic and I look forward to take a ride with CouchBase.
A few questions:
If you are using the best parts of CouchDB, then how is this not a Fork? Will you use any of the code?
Similar query about Memcached / Memebase: What is going on with that code base? How have you merged the two with regards to functionality?
IMHO In order to succeed, you have to provide a bridge from CouchDB to CouchBase, but you said there is no upgrade path. Can you elaborate?
