The Future of CouchDB
What's the future of CouchDB? It's Couchbase.
Huh? So what about Apache CouchDB? Well, that's a great project. I founded it, coded the earliest versions almost completely myself, I've spent a huge amount of blood, sweat and tears on it. I'm very proud of it and the impact it's had. And now I, and the Couchbase team, are mostly moving on. It's not that we think CouchDB isn't awesome. It's that we are creating the successor to it: Couchbase Server. A product and project with similar capabilities and goals, but more faster, more scalable, more customer and developer focused. And definitely not part of Apache.
With Apache CouchDB, much of the focus has been around creating a consensus based, developer community that helps govern and move the project forward. Apache has done, and is doing a good job of that. But for us, it's no longer enough. CouchDB was something I created because I thought an easy to use, peer based, replicating document store was something the world would find useful. And it proved a lot of the ideas were possible and useful and it's been successful beyond my wildest ambitions. But if I had it all to do again, I'd do many things different.
If it sounds like I'm saying Apache was a mistake, I'm not. Apache was a big part in the success of CouchDB, without it CouchDB would not have enjoyed the early success it did. But in my opinion it's reached a point where the consensus based approach has limited the competitiveness of the project. It's not personal, it's business.
And now, as it turns out, I have a chance to do it all again, without the pain of starting from scratch. Building on the previous Apache CouchDB and Membase projects, throwing out what didn't work, and strengthening what does, and advancing great technologies to make something that is developer friendly, high performance, designed for mission critical deployment and mobile integration, and can move faster and more responsively to users and customers needs than a community based project.
Apache CouchDB, as project and community, is in fine shape. And many of us at Couchbase are still contributing back to it. But the future, the one I'm pushing forward on, is Couchbase Server.
And what is my part in building Couchbase? Right now I'm focusing on getting Couchbase 2.0 ready for serious production use. I'm once again an engineer and coder, back in the trenches, designing and writing code, reviewing code and designs, helping other engineers and solving tough problems. And I'm dead serious about making it the easiest, fastest and most reliable NoSQL database. Easy for developers to use, easy to deploy, reliable on single machines or large clusters, and fast as hell. We are building something you can put your mission critical, customer facing business data on, and not feel like you're running a dirty hack.
Soon, to work more closely with the team (and get rid of my nasty Oakland commute), I'll be relocating my family to the Mountain View area. Shit just got real!
And I'm really excited about the work we've got in the pipeline. We are moving more and more of the core database in C/C++, while still using many of the concurrency and reliability design principles we've proven with the Erlang codebase. And Erlang is still going to be part of the product as well, particularly with cluster management, but most of the performance sensitive portions will be moving to over C code. Erlang is still a great language, but when you need top performance and low level control, C is hard to beat.
Anyway, there so much to talk about, to much for one blog post. One of my New Years resolutions is to blog more, and I've got a ton of interesting things to talk about. The trials of tribulations of building a startup and an engineering culture. What's wrong (and right) with Erlang. Bringing forth UnQL. TouchDB for Mobile. And yes, we'll still interoperate with Apache CouchDB and Memcached. But the future is Couchbase.
Ride with me.
Edit
As J. Chris Anderson notes in the comments, Couchbase is completely open source and Apache licensed:
Everything Couchbase does is open source, we have 2 github pages that are very active:https://github.com/couchbaselabs
Probably the most fun place to jump into development is the code review: http://review.couchbase.org/
Let me clarify, if you like Apache CouchDB, stick with it. I'm working on something I think you'll like a lot better. If not, well, there's still Apache CouchDB.
Posted January 4, 2012 11:14 PM
Comments
So, the future of CouchDB is still CouchDB, your future is in Couchbase. Different project, ambiguous name.
At least some confusion in the community has been cleared.
Best wishes.
Amedeo, January 5, 2012 12:25 PM
Thanks for the update.
Will Couch /ahem base be open source in the future? I don't care if it's associated with a foundation or not (and actually, not being with apache will enable you to move more quickly), but I like reading source code :)
Caleb, January 5, 2012 12:35 PM
From Pacific Coast Brewery to The Tied House. Have a great year.
Dan Sickles, January 5, 2012 12:43 PM
Can you please add sections or something to your rambling 9-paragraph blog post? I'd have to be really bored to read that.
Jodo Kast, January 5, 2012 12:43 PM
Congratulations. I hope you succeed with your venture.
And as caleb says, will couchbase be open source?
Felipe, January 5, 2012 1:15 PM
+∞ for finally laying this out here. I think a lot of us suspected as much from the last Couchbase blog post but this puts it in plain language for the "market-speak cynical" developers among us ;-)
Though there's a lot I like about CouchDB warts and all, its real value lay in the brilliantly simple design decisions and the dutiful engineering that implemented them. Between TouchDB and this no-spin post, it's finally clear (to me at least, and I hope many other fans) that "this Membase deal" really is just a continuation of what I've always been hanging my hat on.
natevw, January 5, 2012 1:28 PM
Very helpful post to clear the air. I think I speak for many of us who use and love CouchDB, thanks you for the amazing work, wonderful tools thus far and for striving to push beyond. There are still many questions that come to mind but this blog post and continued community engagement will help ease the minds of many. Live long and prosper. Nanu nanu.
Milan Andric, January 5, 2012 2:54 PM
Unfortunately CouchBase Server is not an option, as one of the most compelling reasons to use CouchDB, namely the restful interface has been removed from it.
And according to Frank Weigel at CouchConf it is not coming back (even though I believe you promised so)
Søren Hilmer, January 5, 2012 4:00 PM
Please make up your mind. Is it C, or is it C++? There is no language called C/C++. What I usually find behind that label is code that needs a C++ compiler, but forbids using any of the most helpful features of the language.
"... when you need top performance and low level control, C is hard to beat."
No, it's not. To beat C, use C++.
If your C++ code isn't way faster, safer, and more maintainable than your C code, you're doing it wrong.
Nathan Myers, January 5, 2012 5:58 PM
Everything Couchbase does is open source, we have 2 github pages that are very active:
https://github.com/couchbaselabs
https://github.com/couchbase
Probably the most fun place to jump into development is the code review: http://review.couchbase.org/
Chris Anderson, January 5, 2012 6:35 PM
Sorry, but this post is ridiculous. It's ok that you want to earn money and it's true it was your idea in the beginning. So it's ok you underline the pros of your product - but please, stop bashing CouchDB to highlight your CouchBase-Baby.
This is unthankful to all the people that helped you in CouchDB's beginnings and it is bad PR for the whole "Couchworld" too.
Go on and earn your money, so nobody has to live from unicorns and stardust - but stay fair!
G'night
Dominique
Dominique S., January 5, 2012 9:26 PM
"What's the future of CouchDB? It's Couchbase."
Sadly not for us. I have bet my company on CouchDB and specifically the unique features that set it apart from other noSQL datastores (RESTful, CouchApps, changes_, peer-peer replication) and all of them are eliminated by CouchBase. I honestly do not think it should have Couch in the name - why not stick to 'MemBase' because clearly that is the product here?
So I now have everything riding on the Apache project and that makes me nervous.
Ewan, January 5, 2012 10:50 PM
You should not move large chunks to C or C++. If you do, it just means you didn't bother to understand the performance bottlenecks. For example, check out what Mercurial does. It has two tiny C modules of 2,600 lines and the rest of the core (60 kloc) is Python. (http://www.ohloh.net/p/mercurial)
You talk about perf issues, and other issues, as the reasons for the fork. They should be broken up and analyzed separately. If you think you can be more responsive to users needs, you don't need to re-write all the code to do that.
KeithCu, January 6, 2012 8:47 AM
"Unfortunately CouchBase Server is not an option, as one of the most compelling reasons to use CouchDB, namely the restful interface has been removed from it."
+1
My jaw dropped - no REST?? This is insane guys.. really disappointed to hear this. Very confusing for you to use "Couch" at all in the name
Graham Yost, January 6, 2012 3:28 PM
>> The future is Couchbase...
Does that future includes current users of CouchDB, Couchrest, Ektorp, etc.? Or do you perhaps begin with the new client base? Can you be more specific about compatibility or transition path? I guess many are facing the same kind of questions now, like: should I drop CouchDB and switch to something else instead of allocating time to designing for an abandoned DB project? How abandoned is it really? What can we hope for? What can we rely upon? C-Erlang-JavaScript-Ektorp-Couchrest-Java-JSON-REST - if there is no support, should each user begin mastering this whole chain of languages? This is not realistic. Proclaiming "the future is Couchbase" without describing upfront what the transition path is, in details, is a sure way to lose the users to competitors (and there are many).
Victor, January 6, 2012 4:30 PM
@Nathan Myers, I see no reason why C++ should be faster than C unless one is using lots of template meta-programming for speed optimization's. The C compilers offer preprocessor meta-programming as well. Other than that, data structures are data structures no matter which language. Now type safety and maintainability is a different story. As for C/C++, maybe it will be written in C with C++ wrappers, or vise versa. I don't see the big deal about his terminology.
Sam, January 6, 2012 7:59 PM
CouchApps are unsupported.
No Futon.
Explicit replication is unsupported
Almost all of the HTTP REST API that makes up the interface for communicating with CouchDB does not exist within Couchbase Server.
Sorry, but if this is the future I prefer the past.
Back to the real Future!
Roberto, January 7, 2012 7:18 AM
@Nathan Myers
Who the f*ck are you? Some nobody who thinks C++ is just great? Probably on the grounds that "Google use it" or some other cargo cult bullsh*t.
Little tip for you. You are not as smart as these guys:
http://www.stgray.com/quotes/cppquotes.html
Ryan Sharp, January 7, 2012 12:24 PM
Actually, that page has some liars claiming that C++ doesn't suck. This one is closer to the truth:
http://harmful.cat-v.org/software/c++/
Ryan Sharp, January 7, 2012 12:30 PM
@Nathan Myers
Oh, the stupidity. It's OK if you don't like C but ignorant statements like "To beat C, use C++" simply make you look bad. Come back when you can support your claims with something more "concrete"...
lurker, January 7, 2012 1:07 PM
Would it be possible to get an overview what were the bottlenecks in using Erlang? I've started learning a bit of Erlang in my spare time, and found it an interesting concept, but some insight would be very useful (especially since CouchDB has been around for quite a while, and probably went through a lot of Erlang's quirks).
Best wishes with the new project nevertheless :)
Branko Majic, January 7, 2012 2:54 PM
"... when you need top performance and low level control, C is hard to beat."
I'm not trying to get into a language war here, but it's worth pointing out that C isn't always hard to beat:
http://scienceblogs.com/goodmath/2006/11/the_c_is_efficient_language_fa.php
- Dirk
Dirk Geurs, January 9, 2012 10:45 AM
It used to be that serious numeric processing was done in Fortran, because Fortran was much faster than C. It still is. Today, serious numeric processing is done in C++, because C++ is much faster than Fortran. This did not happen because Fortran got slower.
I leave it for others to try to explain how it is that "C/C++" is both slower and faster than Fortran.
Nathan Myers, January 10, 2012 3:21 AM
Sorry to see some negative comments here, Damien. Do what you think is best.
Sam, February 1, 2012 10:25 AM
CouchDb is simple. Couchbase server is a tool to seek money. Sorry Damien but community does not need this.
Vladimir, February 21, 2012 2:04 PM
Post a comment