8 ms·

The Future of CouchDB

247 points by badcarl 15y ago

crabasa 15y ago
"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." That sounds like something I very much want, I hope Damien and the team can deliver.
- minikomi 15y ago
  A big part of this will be getting solid, up to date documentation in place. Even though CouchDB is fantastic to work with, when the official docs are out of line with how it actually works, you immediately feel like you're walking on eggshells. That said, I really do like the idea of Everything Restful, and wish them the best!
  - rdtsc 15y ago
    Unfortunately the RESTful api of couchdb is not used, instead memcached protocol is used for inserting docs
    - minikomi 15y ago
      A shame.. Is this a case of what's better for the dev team outweighing what makes it fun to use as a user? Sorry if that seems harsh, but (personally) this plus the simplicity of setting up map/reduce functions and seeing the results directly in futon are what made CouchDB stand out...
      - rdtsc 15y ago
        Yeah I agree. I think they are chasing VC money. Riak is successful so they want to follow suit. But the problem is they are trying to do what Riak does and Riak does what it does best. A second project with largely the same feature is going to have a very hard time displacing a stable product.
- alecthomas 15y ago
  You might want to check out Riak. It is brain dead simple to deploy on one to many machines, very fault tolerant, and the API is simple HTTP.
  - querulous 15y ago
    couchbase seems like riak with the memcache protocol bolted on. most everything that differentiated the two products has been relegated to 'unsupported' in couchbase.
    - dizzyd 15y ago
      Actually, couchbase is exactly the opposite: it's membase with riak bolted on. (Which is arguably worse, IMNSHO) :)
- deleted 15y ago
  [deleted]
daniel_levine 15y ago
I'm super excited about Couchbase and the team. It is already a great product and gets better all the time.
FraaJad 15y ago
The FAQ [1] tells me that Couchasebase Server 2.0 is open source. But, the link to source tarballs and git repos is conspicuously absent from all the pages i've looked through on couchbase.com/org. [1]http://blog.couchbase.com/couchbase-server-20-most-common-questions-and-answers http://blog.couchbase.com/couchbase-server-20-most-common-qu...
- nknight 15y ago
  I suspect this is their repo: https://github.com/couchbase/couchdb https://github.com/couchbase/couchdb
- brianm 15y ago
  The sources all seem to be sitting in https://github.com/membase/ https://github.com/membase/ -- they are componentized, so may be... interesting to work out how to get a running server, but it seems to be there :-) ep_engine looks like the heart of it.
  - dlsspy 15y ago
    We use repo (from android) to put stuff together. The "manifest" repo will pull down the whole world and give you a single unified build system: https://github.com/membase/manifest That also gets you pretty well set up to use our code review system for code submission should you want to contribute: http://review.couchbase.org/ http://review.couchbase.org/ Packaging isn't quite as awesome as I'd like, but all the parts are definitely there.
    - FraaJad 15y ago
      Thanks. A tangential question: Can i still replicate a couchdb database with a couchbase server. Is this documented somewhere?
      - clark-kent 15y ago
        "You cannot replicate between a CouchDB database and Couchbase Server." It's written here http://docs.couchbase.org/couchbase-manual-2.0/couchbase-introduction-migration-couchdb.html http://docs.couchbase.org/couchbase-manual-2.0/couchbase-int... Also, "Almost all of the HTTP REST API that makes up the interface for communicating with CouchDB does not exist within Couchbase Server. The basic document operations for creating, retrieving, updating and deleting information are entirely supported by the memcached protocol." Querying views and map/reduce functions in Couchbase server will be similar to CouchDB except the output will be slightly different.
plinkplonk 15y ago
"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." This is interesting. If I remember correctly, CouchDB was first written in C++ and then moved to Erlang. Now the project has come full circle (which is fine of course).
- Joakal 15y ago
  Oof, seems like a lot of inefficiency in retraining, redocumentation, converting, etc. Not to mention the debugging issues between two different technologies. Why would it be fine?
  - reitzensteinm 15y ago
    I think plinkplonk was saying that it's fine (not necessarily bad) to come full circle in general, not that it will work out in this particular case.
    - plinkplonk 15y ago
      "it's fine (not necessarily bad) to come full circle in general, not that it will work out in this particular case." exactly. I was not saying this step is specifically a bad (or good!) one. I didn't want the thread to devolve into a "which is better Erlang or C++?" flame war. I am sure the devs on the project have good reasons for the change. I just thought it was interesting that the project came full circle.
      - damienkatz 15y ago
        Yes. Erlang is great for proving ideas and making something work reliably. I have mad respect for Erlang, it's the kind of language where one guy can code a whole a distributed database. But when you need high performance and low level control, and you have the resources and team to make it happen, you really can't beat C. I'll write more about that soon.
rdtsc 15y ago
It is interesting, when they dropped Couchbase Single Server I jumped on #couchdb irc channel and said how there will be a developer drain from CouchDB since quite a few of them work for Couchbase and will be working on Couchbase Server only (instead of supporting and sending patches back to CouchDB as well). I got a lot of disagreements and nasty responses back, suggesting that it would not happen and CouchDB is doing awesome, and how this basically doesn't affect CouchDB at all. However here is its creator, urging everyone in so many words to drop CouchDB and switch to Couchbase.
- damienkatz 15y ago
  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.
  - muyuu 15y ago
    Lack of support is a good reason. It's actually pretty much #1 reason why people switch working DB systems at all.
  - opendomain 15y ago
    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?
  - rdtsc 15y ago
    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: * master-to-master replication * _changes feed * Futon * clean RESTful API 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.
epistasis 15y ago
The ideas in CouchDB were really great, but I was very disappointed with what was termed a 1.0 release of CouchDB, as it did not feel ready for prime time, and it ended up torpedoing a project I was working on. I'm also disappointed that it did not quickly improve, and that it appears to be abandoned by it's creator. I am therefore going to avoid Couchbase or anything by it's creator, as I do not trust that it's a foundation that I can build upon.
- damienkatz 15y ago
  That sucks and I'm sorry. I made lots of mistakes, the biggest was trying to run a business instead of the technology. I'm again back where I should be. Whether you choose our technology or not, I wish you success.
  - kayoone 15y ago
    So you mean starting couch.io was a big mistake ? Could you elaborate on that statement, would be interesting to hear what you learned!
    - shykes 15y ago
      I don't think that's what Damien is saying. I think he's saying that, in the process of building couch.io, he should have worn the "technology and product leader" hat instead of the "business leader" hat. In your defense Damien, sometimes there's simply nobody else to do the job and as a founder it's our responsibility to pick up the slack until the right person is hired. Go Couchbase!
  - epistasis 15y ago
    I'm being too petulant. If couchbase turns out very solid with a strong and lively community, or if CouchDB remains solid for a lengthy period of time, of course I'd return, but I'll just wait on the sidelines for others to work out the issues. I hope it turns out great.
smacktoward 15y ago
> if I had it all to do again, I'd do many things different > now, as it turns out, I have a chance to do it all again > throwing out what didn't work, and strengthening what does > not feel like you're running a dirty hack Second-system syndrome [1] ahoy! [1] See http://www.the-wabe.com/notebook/second-system.html http://www.the-wabe.com/notebook/second-system.html, http://c2.com/cgi/wiki?SecondSystemEffect http://c2.com/cgi/wiki?SecondSystemEffect, http://en.wikipedia.org/wiki/Second-system_effect http://en.wikipedia.org/wiki/Second-system_effect, http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html, et al
- JanezStupar 15y ago
  As a guy who was lurking around for basically whole duration of CouchDB development. I would argue that Damien did not fall prey to the second system syndrome. He's just too much of a pragmatic for something like that. The soundness of Damiens engineering views and approaches is hugely similar to those of Linus Torvalds. The truth in my eyes is that CouchDB is misunderstood, the same way Lotus Domino is misunderstood. And if majority of users misunderstand what it is good about then it is not going to be used in an optimal fashion. What I guess that Damien is going to do is build a database that does shit people expected CouchDB to do. And I believe that Damien is a hedge that ensures that goods are going to be delivered.
  - hello_moto 15y ago
    Would you mind to explain why Lotus Domino is misunderstood? This is genuine question by the way, not the kind that ask for debate/arguments. I have friends who do Lotus Domino apps and since I have no idea much about the platform, perhaps you can share story about your statement.
    - JanezStupar 15y ago
      Oh sure. There are a few key points I could analyze, but I will just briefly touch on the CAP theorem. CAP Theorem states that every database engine can satisfy two properties from a pool of three (Consistency, Availability, Partition tolerance). CA type databases are the vast majority of datastores in use out there (everything SQL). While Domino and CouchDB (CouchDB is sort of Free Software Domino) are AP type databases. What does that mean? Well first it means that a lot of the design patterns commonly used in CA CRUD apps goes out the door and requires a different approach. Let me list some: 1. No JOINs, you can either store the referenced data directly in the referee object data OR you can save a key reference and do another query to get related data. It may not seem a lot, but once datasets start growing, this can be quite a pain. 2. No Ad-Hoc querying. There is no concept of "let me open psql and prod the data a bit", not in a production scale database at least. This becomes a contention when customers want a way or a tool that enables them to create arbitrary reports. Usually this can be worked out with a bit of patience and foresight (let me build you another view), but humans suck at that kind of behavior. 3. They are not (really) scalable. Replication in Couch and Domino is not really intended as performance measure. It is more a failover and data portability measure. Also in this kind of distributed database, you need to pay attention to sort of "write jurisdiction". Couch touts "advanced conflict resolution mechanisms", which is true until the same field is modified in two different replicas, it is impossible to merge this kind of conflict without loosing data and human must be used to decide what gets to stay. The issue with this is that people seeing "replication conflict", don't think "Oh we had a race condition, let me resolve this" - they think "Oh its the stupid, crappy, goddamn database again, we really should move to SQL". 4. No schema. Document is a bucket, you throw in whatever you please. This may be a good thing or a bad thing. Depends. But if you are too enthusiastic about it, you might wake up to quite a head ache one morning in a couple of years. 5.(Couch specific) Map/Reduce: Perhaps originally it was intended to become a cluster level querying mechanism, but the truth is that albeit it being a very smart indexing mechanism, people associated it with Google's MapReduce (which was a big, big buzzword back in 2006), which led to a lot of disappointment on the users side. 6.(Domino specific) IBM doesn't really know what to do with Domino platform. They tried to kill it, but failed at it. Then forgot to market it. Then remembered to market it, but forgot to develop it. Then remembered to develop it, but failed at it. Then bolted some Java Abomination on top of it. Its the kind of MBA stuff nobody really understands. Why is this important? Because Domino is pretty good application platform for developing "access" type applications for businesses and IBM hates that part, because this kind of stuff is IBM GCS turf and why would they let you develop internal app for 1000$, when they can rob you of 50$K? The main point is that with Couch/Domino you can do pretty much everything you can do with relational data stores, but it will look different. It will feel different and it means some compromises you might not expect (or are at least not used to). Honestly all things considered, after years of experience there are indeed very few problems that call exactly for a Couch/Domino type database. However I certainly see how a DB of this kind should find its place in each and every major information system.
zerothehero 15y ago
This post is pretty vague. Having heard of Couch a few times over the years but not used it, it would been more helpful if he said something like: "I started a company and forked the open source CouchDB project that I founded. The company and new commercial product is CouchBase and it will be better for these reasons..." And I would be curious about some examples of where the open governance limited the CouchDB project as he's implying. Those seem to be orthogonal things -- he could have just created a non-Apache open source project rather than making it commercial. He is beating around the bush so much and using such vague wording that I wonder if he is hiding something, or just ashamed that he's cashing in on his creation. There's no shame in making money and no shame in making a commercial fork of your own project. But the CouchBase website looks awfully "enterprisey" now and I think there is some shame in that...
- smokinn 15y ago
  That's not what he said at all. I don't use couchdb either but I do follow the nosql space a little and what I read was that he's creating an all-new project. Couchdb is an Apache foundation-led project and will continue on its own path. Couchbase is an all-new project that will solve some of the same use-cases but be better at scaling. It's not a fork at all.
- gizzlon 15y ago
  True, the website is full of bs. But since it actually talks about the products and technoloies (kind of) it only rates 6 of 10 on my enterprisey-bullsht scale. Others are far worse (*couch* puppetlabs.com *couch* ;)
clark-kent 15y ago
This feels like bad news for CouchDB users, since they will need to re-write code and re-learn a new system if they choose to migrate to Couchbase Server. It's better to promote Couchbase server for it's own merits rather than promoting it as the future of CouchDB.
grout 15y ago
This is what happens when people with the kind of crazy that broke HP and Palm and Compaq decide to play with open source projects. Clue: Dealmaking is not codemaking.
deleted 15y ago
[deleted]
perfunctory 15y ago
I'm glad I didn't invest too much time into CouchDB
digispaghetti 15y ago
Having used CouchDB, and seeing what's being done with CouchBase I'm actually glad to see this. The problem at the moment is the fragmentation - CouchBase doesn't have all the features of CouchDB - but what it lacks, it makes up for in the memcached features which start to put it on a par with the likes of Redis for speed, with a much simpler API that other document store databases (you can't beat the language of the web for simplicity vs a binary driver) Hopefully it will be a smooth transition and I will most likely hold off using CouchBase right away - but I foresee me using it in the next year for sure.
rb2k_ 15y ago
I looked at couchbase and it seems somewhat user-friendly. The way to preview your created views by using only a subset of data is nice. Another nice thing is the split into ?16? different databases that allow compaction to occur on a smaller level rather than having to compact the whole 60 gb file at once The downside for me so far: - I couldn't find any way to import my current couchbase single server data over to couchbase. - The old couchdb webinterface (futon) made browsing through data easy, the couchbase interface seems to make this a bit more complicated. (Maybe I didn't look in the right places?) - I couldn't figure out if I can still hook up the _changes feed to elasticsearch
- gr2m 15y ago
  that's because there is no _changes feed in the current couchbase 2.0 server.
  - rb2k_ 15y ago
    Oh... that is a shame. I also got confused by the elasticsearch repo in the couchbase project on github: https://github.com/couchbase/elasticsearch https://github.com/couchbase/elasticsearch I don't see any external commits though
- dlsspy 15y ago
  We have something higher-performance than _changes and have had elasticsearch support as a third-party plugin for a while. We don't have firm plans to bring it in first-class, but we do think it would be beneficial to many of our users.
  - rb2k_ 15y ago
    Could you point me to that plugin? (I assume it's a river. Searching for "couchbase river elasticsearch" doesn't really return anything though.)
gr2m 15y ago
The features I got exited most about (and am relying on today) are: databases per user, continuous replication and the _changes. From my understanding, these are not part of the CouchBase server, right? What are the future plans for these features? Telling from the 2 CouchConfs I've been to, Couchbase is focused on huge one-db setups, distributed and fast ... but what about the "database per user" setup? Is this going to die?
skrebbel 15y ago
I think this is an excellent move that fits with the current times. If I'm going to use a DB for production use, I want it to be well supported, well documented, easy to use, etcetera. Very few consensus-based projects I know reach all those goals. CouchDB sure hasn't entirely. If this move is going to improve on that, I may very well end up a Couchbase customer.
thesorrow 15y ago
So if i understand right, everyone is trying to be RESTful except Couchbase ?
henchan 15y ago
This is really bad news. Not exactly out of the blue, but there's no ambiguity now. http://docs.couchbase.org/couchbase-manual-2.0/couchbase-introduction-migration-couchdb.html http://docs.couchbase.org/couchbase-manual-2.0/couchbase-int... There's such a wide functional gap between CouchDB and CouchBase that it feels like the heart has been ripped out and placed into an entirely different beast. Of course the Apache project is still there, but I have grave doubt over whether it will continue to be actively developed. To ease anxieties, it would be great to see a roadmap or some statement of commitment from those remaining in the CouchDB community. Including Iris and Cloudant.
nephics 15y ago
It would have been a bold move, if Damien had left the "Couch" name with Apache CouchDB, and released his CouchBase product under another name. Also, this would have liberated him from having to distance himself from CouchDB, Erlang and Apache, when promoting his new product. CouchDB is dead, long live Apache CouchDB.
- mark_l_watson 15y ago
  I agree with what I think that you and other people here are saying: the Apache CouchDB project will continue to be supported by a good community so there is very little technical risk for using CouchDB. BTW, I think that datastore as a service companies like Cloudant, MongoHQ (and many other good companies) are a great convenience, but for self hosting, I wonder why anyone really needs support for CouchDB, MongoDB, etc. unless they have very large deployments.
  - mauricio 15y ago
    I think it's a little unfair to lump Cloudant in with MongoHQ and label them a "datastore as a service" company. You should check out what they've done with BigCouch and their annoucement today about how they will be committing the BigCouch changes back into CouchDB proper.
sgentle 15y ago
Shame. I really like CouchApp. It felt like CouchDB was one rails moment away from being a whole new way to develop web apps, where the DB, the client, and the application were all part of the same glorious union rather than being a bunch of ugly parts bolted together.
- minikomi 15y ago
  Yeah, I loved the feeling of bluring the lines and developing everything as one whole than piping bits from one box into another.
- sausagefeet 15y ago
  There is always MegLev - http://maglev.github.com/ http://maglev.github.com/
rubyrescue 15y ago
This is NOT second system syndrome. This is business, pure and simple. I had a long, LONG series of emails and calls with CouchBase about commercial support for Couch. We have some big production apps on it. When it got down to time to pay for support, they told me (this is 2 months ago) in a rare and unusual bit of candor, that they were going to drop Couch in less than six months, so did I want to buy commercial support for just six months? I told them not only do I not want commercial support, but I just got so freaked out I would not recommend couch for future projects to clients, because it was obvious that internally the team had moved on. They asked me not to tell anyone so I didn't, but now that this is out there I can say what I deducted from our discussions: Couch doesn't make any money; MemBase does. Period. Kevin Smith at Opscode said they're moving away from Couch (and to MySQL) as Couch just doesn't scale. No finely grained reader/writer locks, one reader/writer thread/db, huge and random delays due to checkpointing that can make the server inoperable, difficulty ever finishing a view checkpoint under load, etc. I think he's right - it's been abandoned as a platform. It's absolutely their prerogative to move on and it seems like the right decision, but it's not a technical decision. The reality is that CouchDB is largely a product running small, toy apps, written by people who won't PAY anything for support. MemBase is being used by big companies with a lot of money to spend on commercial support and enterprise features. Actually there is still one case where I recommend Couch and it's when you need the mobile sync features. I doubt that they'll make those a priority anytime soon on the MemBase product (at least I haven't seen or heard anything).
- catwell 15y ago
  Interesting. I agree with you when you say what makes Couch interesting is its sync (mobile or not) features. There are lots of DBs out there that focus on scale and not enough on sync. If they want to win the mobile market though, they will have to re-implement the DB in C. Erlang was a good choice on the server but in the current mobile ecosystem it's clearly a drawback.
  - jchrisa 15y ago
    We have TouchDB, written in ObjC, still in early development, but it syncs with CouchDB and has a 100ms startup time. iOS TouchDB: https://github.com/couchbaselabs/TouchDB-iOS https://github.com/couchbaselabs/TouchDB-iOS We are also exploring TouchDB on Android. If you want to join the community and help us build these and other wonders, we do it in this group: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase
antirez 15y ago
Probably it is very hard to create a company around an open source project without disrupting part of the open source ecosystem around it... on the other hand it is important to create some kind of structure to pay the developers to continue working on the project. I'm not sure what I would do without VMware helping Redis... but I guess that some decent compromise should exist, like creating a support company for the software but leaving the project itself as an open source effort with it's own separated site, mailing list, and so forth. There is also an ethical problem IMHO. For instance is Redis mine? I guess it is not: VMware is funding the development so I can write code thanks to Vmware. Pieter is contributing a lot of code. The community is helping a lot the project: with talks spreading the word, helping on the mailing list, helping to fix bugs, and so forth. My guess is that the developers really conceptually "own" a very small piece of the pie, and when they create business around an open source software, they should take this in mind otherwise it is simple to involuntarily use work/efforts that other people did in the past and turn it into your business. It's not easy however... as: the end users should be happy and well served, and the software should not just be "open source" but an open process, with an open community, and so forth. At the same time the developers should pay their bills without issues and earn enough to avoid being tempted to joined company XYZ instead of working to their project. It's not trivial to have all this together I guess, and I feel very lucky that there is VMware making this simple for me, but not all the open source developers are equally fortunate so I guess it is crucial that the open source community keeps working on different ideas to find viable solutions.
- catwell 15y ago
  There are alternate models, eg. LuaJIT http://luajit.org/sponsors.html http://luajit.org/sponsors.html On a side note: who owns the Redis brand (and logo)?
  - mikemike 15y ago
    [LuaJIT author here:] I'm not so sure the business model of LuaJIT can easily be applied to other open source projects. I mean, I've been running a business for more than 15 years. I basically downscaled consulting as I've acquired paid open source work. It pays less, but I'm happier now. I think you'd have a hard time doing this from zero, without some backup plan or enough funds of your own. Well, have a look at the price point of scripting languages, toolchains and such. Getting a vague business plan for an open source project in the toolchain/middleware business through a VC round? I don't think so. Business knowledge was essential, too. Negotiating open source sponsorship contracts with corporate lawyers for half a year is not that easy. Some companies were extremely easy to work with, but I guess sponsoring open source projects is simply not an established business procedure at most companies. I don't think you could possibly afford to hire an international IP lawyer to do this for you. Actually it was the economic downturn of 2008 which triggered all of this. The (rarely followed) advice is to invest in a downturn, because you'll be the first one to come out ahead in the following upturn. Ok, so I invested my time and knowledge into a new project (#). It worked out for me, but in retrospect I realize it was a high risk investment. Final words: you think we're seeing some kind of downturn again? Carefully assess the risks and the potential for yourself. But don't be shy if you're onto something good. Innovate, don't replicate. (#) LuaJIT 2.x is a complete rewrite, using the experience gained working on LuaJIT 1.x, but very little of its code. It's been on my backburner since 2007 and the first public release of LuaJIT 2.0 was at the end of 2009. One might say it's about a two man-year investment before it started to pay back. Most of the time was spent on doing research and prototyping rather than writing code. I coded and then threw away almost three complete virtual machines in the process, because these approaches turned out to be dead ends. I bet you'd need a lot of courage to explain this to a VC. ;-)
jhawk28 15y ago
I like a lot of things about CouchBase, but is it going to get the replication approach that CouchDB has? That is exactly what I am needing right now.
ultimatewarrior 15y ago
Something is wrong with both CouchDB and Damien
czue 15y ago
I found it surprising that Damien comes off so completely unapologetic about his decision to abandon Apache and the CouchDB community. As a long time CouchDB user and open source believer the whole tone of his post leaves a dirty taste in my mouth.
robterrell 15y ago
I've spent the past year building an app on CouchDB and I've really enjoyed using it. The couch.io to CouchBase transition was poorly communicated, so I'm glad Damien's made such a clear statement of intent. Clearly I'm going to have to stick with Apache CouchDB for now. I was interested in moving to CouchBase, but that's surprisingly difficult: 1. There's no easy transition for my data. I thought I could just install CouchBase and replicate from my existing CouchDB -- nope, can't be done. Huh? But why... 2. It's partly because CouchBase drops the CouchDB REST API. Which also means, none of my existing code works with it. So I guess it's no big deal that my data won't move over, because my app won't be able to retrieve it anyway. Because there's no easy transition, they've created a situation where anyone considering a move to CouchBase is just as likely to re-evaluate all of the other document (or k/v) stores.

247 points by badcarl 15y ago

"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." That sounds like something I very much want, I hope Damien and the team can deliver.

minikomi 15y ago
A big part of this will be getting solid, up to date documentation in place. Even though CouchDB is fantastic to work with, when the official docs are out of line with how it actually works, you immediately feel like you're walking on eggshells. That said, I really do like the idea of Everything Restful, and wish them the best!
- rdtsc 15y ago
  Unfortunately the RESTful api of couchdb is not used, instead memcached protocol is used for inserting docs
  - minikomi 15y ago
    A shame.. Is this a case of what's better for the dev team outweighing what makes it fun to use as a user? Sorry if that seems harsh, but (personally) this plus the simplicity of setting up map/reduce functions and seeing the results directly in futon are what made CouchDB stand out...
    - rdtsc 15y ago
      Yeah I agree. I think they are chasing VC money. Riak is successful so they want to follow suit. But the problem is they are trying to do what Riak does and Riak does what it does best. A second project with largely the same feature is going to have a very hard time displacing a stable product.
alecthomas 15y ago
You might want to check out Riak. It is brain dead simple to deploy on one to many machines, very fault tolerant, and the API is simple HTTP.
- querulous 15y ago
  couchbase seems like riak with the memcache protocol bolted on. most everything that differentiated the two products has been relegated to 'unsupported' in couchbase.
  - dizzyd 15y ago
    Actually, couchbase is exactly the opposite: it's membase with riak bolted on. (Which is arguably worse, IMNSHO) :)
deleted 15y ago
[deleted]

daniel_levine 15y ago

I'm super excited about Couchbase and the team. It is already a great product and gets better all the time.

FraaJad 15y ago

The FAQ [1] tells me that Couchasebase Server 2.0 is open source. But, the link to source tarballs and git repos is conspicuously absent from all the pages i've looked through on couchbase.com/org. [1]http://blog.couchbase.com/couchbase-server-20-most-common-questions-and-answers http://blog.couchbase.com/couchbase-server-20-most-common-qu...

nknight 15y ago
I suspect this is their repo: https://github.com/couchbase/couchdb https://github.com/couchbase/couchdb
brianm 15y ago
The sources all seem to be sitting in https://github.com/membase/ https://github.com/membase/ -- they are componentized, so may be... interesting to work out how to get a running server, but it seems to be there :-) ep_engine looks like the heart of it.
- dlsspy 15y ago
  We use repo (from android) to put stuff together. The "manifest" repo will pull down the whole world and give you a single unified build system: https://github.com/membase/manifest That also gets you pretty well set up to use our code review system for code submission should you want to contribute: http://review.couchbase.org/ http://review.couchbase.org/ Packaging isn't quite as awesome as I'd like, but all the parts are definitely there.
  - FraaJad 15y ago
    Thanks. A tangential question: Can i still replicate a couchdb database with a couchbase server. Is this documented somewhere?
    - clark-kent 15y ago
      "You cannot replicate between a CouchDB database and Couchbase Server." It's written here http://docs.couchbase.org/couchbase-manual-2.0/couchbase-introduction-migration-couchdb.html http://docs.couchbase.org/couchbase-manual-2.0/couchbase-int... Also, "Almost all of the HTTP REST API that makes up the interface for communicating with CouchDB does not exist within Couchbase Server. The basic document operations for creating, retrieving, updating and deleting information are entirely supported by the memcached protocol." Querying views and map/reduce functions in Couchbase server will be similar to CouchDB except the output will be slightly different.

plinkplonk 15y ago

"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." This is interesting. If I remember correctly, CouchDB was first written in C++ and then moved to Erlang. Now the project has come full circle (which is fine of course).

Joakal 15y ago
Oof, seems like a lot of inefficiency in retraining, redocumentation, converting, etc. Not to mention the debugging issues between two different technologies. Why would it be fine?
- reitzensteinm 15y ago
  I think plinkplonk was saying that it's fine (not necessarily bad) to come full circle in general, not that it will work out in this particular case.
  - plinkplonk 15y ago
    "it's fine (not necessarily bad) to come full circle in general, not that it will work out in this particular case." exactly. I was not saying this step is specifically a bad (or good!) one. I didn't want the thread to devolve into a "which is better Erlang or C++?" flame war. I am sure the devs on the project have good reasons for the change. I just thought it was interesting that the project came full circle.
    - damienkatz 15y ago
      Yes. Erlang is great for proving ideas and making something work reliably. I have mad respect for Erlang, it's the kind of language where one guy can code a whole a distributed database. But when you need high performance and low level control, and you have the resources and team to make it happen, you really can't beat C. I'll write more about that soon.

rdtsc 15y ago

It is interesting, when they dropped Couchbase Single Server I jumped on #couchdb irc channel and said how there will be a developer drain from CouchDB since quite a few of them work for Couchbase and will be working on Couchbase Server only (instead of supporting and sending patches back to CouchDB as well). I got a lot of disagreements and nasty responses back, suggesting that it would not happen and CouchDB is doing awesome, and how this basically doesn't affect CouchDB at all. However here is its creator, urging everyone in so many words to drop CouchDB and switch to Couchbase.

damienkatz 15y ago
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.
- muyuu 15y ago
  Lack of support is a good reason. It's actually pretty much #1 reason why people switch working DB systems at all.
- opendomain 15y ago
  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?
- rdtsc 15y ago
  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: * master-to-master replication * _changes feed * Futon * clean RESTful API 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.

epistasis 15y ago

The ideas in CouchDB were really great, but I was very disappointed with what was termed a 1.0 release of CouchDB, as it did not feel ready for prime time, and it ended up torpedoing a project I was working on. I'm also disappointed that it did not quickly improve, and that it appears to be abandoned by it's creator. I am therefore going to avoid Couchbase or anything by it's creator, as I do not trust that it's a foundation that I can build upon.

damienkatz 15y ago
That sucks and I'm sorry. I made lots of mistakes, the biggest was trying to run a business instead of the technology. I'm again back where I should be. Whether you choose our technology or not, I wish you success.
- kayoone 15y ago
  So you mean starting couch.io was a big mistake ? Could you elaborate on that statement, would be interesting to hear what you learned!
  - shykes 15y ago
    I don't think that's what Damien is saying. I think he's saying that, in the process of building couch.io, he should have worn the "technology and product leader" hat instead of the "business leader" hat. In your defense Damien, sometimes there's simply nobody else to do the job and as a founder it's our responsibility to pick up the slack until the right person is hired. Go Couchbase!
- epistasis 15y ago
  I'm being too petulant. If couchbase turns out very solid with a strong and lively community, or if CouchDB remains solid for a lengthy period of time, of course I'd return, but I'll just wait on the sidelines for others to work out the issues. I hope it turns out great.

smacktoward 15y ago

> if I had it all to do again, I'd do many things different > now, as it turns out, I have a chance to do it all again > throwing out what didn't work, and strengthening what does > not feel like you're running a dirty hack Second-system syndrome [1] ahoy! [1] See http://www.the-wabe.com/notebook/second-system.html http://www.the-wabe.com/notebook/second-system.html, http://c2.com/cgi/wiki?SecondSystemEffect http://c2.com/cgi/wiki?SecondSystemEffect, http://en.wikipedia.org/wiki/Second-system_effect http://en.wikipedia.org/wiki/Second-system_effect, http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html, et al

JanezStupar 15y ago
As a guy who was lurking around for basically whole duration of CouchDB development. I would argue that Damien did not fall prey to the second system syndrome. He's just too much of a pragmatic for something like that. The soundness of Damiens engineering views and approaches is hugely similar to those of Linus Torvalds. The truth in my eyes is that CouchDB is misunderstood, the same way Lotus Domino is misunderstood. And if majority of users misunderstand what it is good about then it is not going to be used in an optimal fashion. What I guess that Damien is going to do is build a database that does shit people expected CouchDB to do. And I believe that Damien is a hedge that ensures that goods are going to be delivered.
- hello_moto 15y ago
  Would you mind to explain why Lotus Domino is misunderstood? This is genuine question by the way, not the kind that ask for debate/arguments. I have friends who do Lotus Domino apps and since I have no idea much about the platform, perhaps you can share story about your statement.
  - JanezStupar 15y ago
    Oh sure. There are a few key points I could analyze, but I will just briefly touch on the CAP theorem. CAP Theorem states that every database engine can satisfy two properties from a pool of three (Consistency, Availability, Partition tolerance). CA type databases are the vast majority of datastores in use out there (everything SQL). While Domino and CouchDB (CouchDB is sort of Free Software Domino) are AP type databases. What does that mean? Well first it means that a lot of the design patterns commonly used in CA CRUD apps goes out the door and requires a different approach. Let me list some: 1. No JOINs, you can either store the referenced data directly in the referee object data OR you can save a key reference and do another query to get related data. It may not seem a lot, but once datasets start growing, this can be quite a pain. 2. No Ad-Hoc querying. There is no concept of "let me open psql and prod the data a bit", not in a production scale database at least. This becomes a contention when customers want a way or a tool that enables them to create arbitrary reports. Usually this can be worked out with a bit of patience and foresight (let me build you another view), but humans suck at that kind of behavior. 3. They are not (really) scalable. Replication in Couch and Domino is not really intended as performance measure. It is more a failover and data portability measure. Also in this kind of distributed database, you need to pay attention to sort of "write jurisdiction". Couch touts "advanced conflict resolution mechanisms", which is true until the same field is modified in two different replicas, it is impossible to merge this kind of conflict without loosing data and human must be used to decide what gets to stay. The issue with this is that people seeing "replication conflict", don't think "Oh we had a race condition, let me resolve this" - they think "Oh its the stupid, crappy, goddamn database again, we really should move to SQL". 4. No schema. Document is a bucket, you throw in whatever you please. This may be a good thing or a bad thing. Depends. But if you are too enthusiastic about it, you might wake up to quite a head ache one morning in a couple of years. 5.(Couch specific) Map/Reduce: Perhaps originally it was intended to become a cluster level querying mechanism, but the truth is that albeit it being a very smart indexing mechanism, people associated it with Google's MapReduce (which was a big, big buzzword back in 2006), which led to a lot of disappointment on the users side. 6.(Domino specific) IBM doesn't really know what to do with Domino platform. They tried to kill it, but failed at it. Then forgot to market it. Then remembered to market it, but forgot to develop it. Then remembered to develop it, but failed at it. Then bolted some Java Abomination on top of it. Its the kind of MBA stuff nobody really understands. Why is this important? Because Domino is pretty good application platform for developing "access" type applications for businesses and IBM hates that part, because this kind of stuff is IBM GCS turf and why would they let you develop internal app for 1000$, when they can rob you of 50$K? The main point is that with Couch/Domino you can do pretty much everything you can do with relational data stores, but it will look different. It will feel different and it means some compromises you might not expect (or are at least not used to). Honestly all things considered, after years of experience there are indeed very few problems that call exactly for a Couch/Domino type database. However I certainly see how a DB of this kind should find its place in each and every major information system.

zerothehero 15y ago

This post is pretty vague. Having heard of Couch a few times over the years but not used it, it would been more helpful if he said something like: "I started a company and forked the open source CouchDB project that I founded. The company and new commercial product is CouchBase and it will be better for these reasons..." And I would be curious about some examples of where the open governance limited the CouchDB project as he's implying. Those seem to be orthogonal things -- he could have just created a non-Apache open source project rather than making it commercial. He is beating around the bush so much and using such vague wording that I wonder if he is hiding something, or just ashamed that he's cashing in on his creation. There's no shame in making money and no shame in making a commercial fork of your own project. But the CouchBase website looks awfully "enterprisey" now and I think there is some shame in that...

smokinn 15y ago
That's not what he said at all. I don't use couchdb either but I do follow the nosql space a little and what I read was that he's creating an all-new project. Couchdb is an Apache foundation-led project and will continue on its own path. Couchbase is an all-new project that will solve some of the same use-cases but be better at scaling. It's not a fork at all.
gizzlon 15y ago
True, the website is full of bs. But since it actually talks about the products and technoloies (kind of) it only rates 6 of 10 on my enterprisey-bullsht scale. Others are far worse (*couch* puppetlabs.com *couch* ;)

clark-kent 15y ago

This feels like bad news for CouchDB users, since they will need to re-write code and re-learn a new system if they choose to migrate to Couchbase Server. It's better to promote Couchbase server for it's own merits rather than promoting it as the future of CouchDB.

grout 15y ago

This is what happens when people with the kind of crazy that broke HP and Palm and Compaq decide to play with open source projects. Clue: Dealmaking is not codemaking.

deleted 15y ago

[deleted]

perfunctory 15y ago

I'm glad I didn't invest too much time into CouchDB

digispaghetti 15y ago

Having used CouchDB, and seeing what's being done with CouchBase I'm actually glad to see this. The problem at the moment is the fragmentation - CouchBase doesn't have all the features of CouchDB - but what it lacks, it makes up for in the memcached features which start to put it on a par with the likes of Redis for speed, with a much simpler API that other document store databases (you can't beat the language of the web for simplicity vs a binary driver) Hopefully it will be a smooth transition and I will most likely hold off using CouchBase right away - but I foresee me using it in the next year for sure.

rb2k_ 15y ago

I looked at couchbase and it seems somewhat user-friendly. The way to preview your created views by using only a subset of data is nice. Another nice thing is the split into ?16? different databases that allow compaction to occur on a smaller level rather than having to compact the whole 60 gb file at once The downside for me so far: - I couldn't find any way to import my current couchbase single server data over to couchbase. - The old couchdb webinterface (futon) made browsing through data easy, the couchbase interface seems to make this a bit more complicated. (Maybe I didn't look in the right places?) - I couldn't figure out if I can still hook up the _changes feed to elasticsearch

gr2m 15y ago
that's because there is no _changes feed in the current couchbase 2.0 server.
- rb2k_ 15y ago
  Oh... that is a shame. I also got confused by the elasticsearch repo in the couchbase project on github: https://github.com/couchbase/elasticsearch https://github.com/couchbase/elasticsearch I don't see any external commits though
dlsspy 15y ago
We have something higher-performance than _changes and have had elasticsearch support as a third-party plugin for a while. We don't have firm plans to bring it in first-class, but we do think it would be beneficial to many of our users.
- rb2k_ 15y ago
  Could you point me to that plugin? (I assume it's a river. Searching for "couchbase river elasticsearch" doesn't really return anything though.)

gr2m 15y ago

The features I got exited most about (and am relying on today) are: databases per user, continuous replication and the _changes. From my understanding, these are not part of the CouchBase server, right? What are the future plans for these features? Telling from the 2 CouchConfs I've been to, Couchbase is focused on huge one-db setups, distributed and fast ... but what about the "database per user" setup? Is this going to die?

skrebbel 15y ago

I think this is an excellent move that fits with the current times. If I'm going to use a DB for production use, I want it to be well supported, well documented, easy to use, etcetera. Very few consensus-based projects I know reach all those goals. CouchDB sure hasn't entirely. If this move is going to improve on that, I may very well end up a Couchbase customer.

thesorrow 15y ago

So if i understand right, everyone is trying to be RESTful except Couchbase ?

henchan 15y ago

This is really bad news. Not exactly out of the blue, but there's no ambiguity now. http://docs.couchbase.org/couchbase-manual-2.0/couchbase-introduction-migration-couchdb.html http://docs.couchbase.org/couchbase-manual-2.0/couchbase-int... There's such a wide functional gap between CouchDB and CouchBase that it feels like the heart has been ripped out and placed into an entirely different beast. Of course the Apache project is still there, but I have grave doubt over whether it will continue to be actively developed. To ease anxieties, it would be great to see a roadmap or some statement of commitment from those remaining in the CouchDB community. Including Iris and Cloudant.

nephics 15y ago

It would have been a bold move, if Damien had left the "Couch" name with Apache CouchDB, and released his CouchBase product under another name. Also, this would have liberated him from having to distance himself from CouchDB, Erlang and Apache, when promoting his new product. CouchDB is dead, long live Apache CouchDB.

mark_l_watson 15y ago
I agree with what I think that you and other people here are saying: the Apache CouchDB project will continue to be supported by a good community so there is very little technical risk for using CouchDB. BTW, I think that datastore as a service companies like Cloudant, MongoHQ (and many other good companies) are a great convenience, but for self hosting, I wonder why anyone really needs support for CouchDB, MongoDB, etc. unless they have very large deployments.
- mauricio 15y ago
  I think it's a little unfair to lump Cloudant in with MongoHQ and label them a "datastore as a service" company. You should check out what they've done with BigCouch and their annoucement today about how they will be committing the BigCouch changes back into CouchDB proper.

sgentle 15y ago

Shame. I really like CouchApp. It felt like CouchDB was one rails moment away from being a whole new way to develop web apps, where the DB, the client, and the application were all part of the same glorious union rather than being a bunch of ugly parts bolted together.

minikomi 15y ago
Yeah, I loved the feeling of bluring the lines and developing everything as one whole than piping bits from one box into another.
sausagefeet 15y ago
There is always MegLev - http://maglev.github.com/ http://maglev.github.com/

rubyrescue 15y ago

This is NOT second system syndrome. This is business, pure and simple. I had a long, LONG series of emails and calls with CouchBase about commercial support for Couch. We have some big production apps on it. When it got down to time to pay for support, they told me (this is 2 months ago) in a rare and unusual bit of candor, that they were going to drop Couch in less than six months, so did I want to buy commercial support for just six months? I told them not only do I not want commercial support, but I just got so freaked out I would not recommend couch for future projects to clients, because it was obvious that internally the team had moved on. They asked me not to tell anyone so I didn't, but now that this is out there I can say what I deducted from our discussions: Couch doesn't make any money; MemBase does. Period. Kevin Smith at Opscode said they're moving away from Couch (and to MySQL) as Couch just doesn't scale. No finely grained reader/writer locks, one reader/writer thread/db, huge and random delays due to checkpointing that can make the server inoperable, difficulty ever finishing a view checkpoint under load, etc. I think he's right - it's been abandoned as a platform. It's absolutely their prerogative to move on and it seems like the right decision, but it's not a technical decision. The reality is that CouchDB is largely a product running small, toy apps, written by people who won't PAY anything for support. MemBase is being used by big companies with a lot of money to spend on commercial support and enterprise features. Actually there is still one case where I recommend Couch and it's when you need the mobile sync features. I doubt that they'll make those a priority anytime soon on the MemBase product (at least I haven't seen or heard anything).

catwell 15y ago
Interesting. I agree with you when you say what makes Couch interesting is its sync (mobile or not) features. There are lots of DBs out there that focus on scale and not enough on sync. If they want to win the mobile market though, they will have to re-implement the DB in C. Erlang was a good choice on the server but in the current mobile ecosystem it's clearly a drawback.
- jchrisa 15y ago
  We have TouchDB, written in ObjC, still in early development, but it syncs with CouchDB and has a 100ms startup time. iOS TouchDB: https://github.com/couchbaselabs/TouchDB-iOS https://github.com/couchbaselabs/TouchDB-iOS We are also exploring TouchDB on Android. If you want to join the community and help us build these and other wonders, we do it in this group: https://groups.google.com/forum/#!forum/mobile-couchbase https://groups.google.com/forum/#!forum/mobile-couchbase

antirez 15y ago

Probably it is very hard to create a company around an open source project without disrupting part of the open source ecosystem around it... on the other hand it is important to create some kind of structure to pay the developers to continue working on the project. I'm not sure what I would do without VMware helping Redis... but I guess that some decent compromise should exist, like creating a support company for the software but leaving the project itself as an open source effort with it's own separated site, mailing list, and so forth. There is also an ethical problem IMHO. For instance is Redis mine? I guess it is not: VMware is funding the development so I can write code thanks to Vmware. Pieter is contributing a lot of code. The community is helping a lot the project: with talks spreading the word, helping on the mailing list, helping to fix bugs, and so forth. My guess is that the developers really conceptually "own" a very small piece of the pie, and when they create business around an open source software, they should take this in mind otherwise it is simple to involuntarily use work/efforts that other people did in the past and turn it into your business. It's not easy however... as: the end users should be happy and well served, and the software should not just be "open source" but an open process, with an open community, and so forth. At the same time the developers should pay their bills without issues and earn enough to avoid being tempted to joined company XYZ instead of working to their project. It's not trivial to have all this together I guess, and I feel very lucky that there is VMware making this simple for me, but not all the open source developers are equally fortunate so I guess it is crucial that the open source community keeps working on different ideas to find viable solutions.

catwell 15y ago
There are alternate models, eg. LuaJIT http://luajit.org/sponsors.html http://luajit.org/sponsors.html On a side note: who owns the Redis brand (and logo)?
- mikemike 15y ago
  [LuaJIT author here:] I'm not so sure the business model of LuaJIT can easily be applied to other open source projects. I mean, I've been running a business for more than 15 years. I basically downscaled consulting as I've acquired paid open source work. It pays less, but I'm happier now. I think you'd have a hard time doing this from zero, without some backup plan or enough funds of your own. Well, have a look at the price point of scripting languages, toolchains and such. Getting a vague business plan for an open source project in the toolchain/middleware business through a VC round? I don't think so. Business knowledge was essential, too. Negotiating open source sponsorship contracts with corporate lawyers for half a year is not that easy. Some companies were extremely easy to work with, but I guess sponsoring open source projects is simply not an established business procedure at most companies. I don't think you could possibly afford to hire an international IP lawyer to do this for you. Actually it was the economic downturn of 2008 which triggered all of this. The (rarely followed) advice is to invest in a downturn, because you'll be the first one to come out ahead in the following upturn. Ok, so I invested my time and knowledge into a new project (#). It worked out for me, but in retrospect I realize it was a high risk investment. Final words: you think we're seeing some kind of downturn again? Carefully assess the risks and the potential for yourself. But don't be shy if you're onto something good. Innovate, don't replicate. (#) LuaJIT 2.x is a complete rewrite, using the experience gained working on LuaJIT 1.x, but very little of its code. It's been on my backburner since 2007 and the first public release of LuaJIT 2.0 was at the end of 2009. One might say it's about a two man-year investment before it started to pay back. Most of the time was spent on doing research and prototyping rather than writing code. I coded and then threw away almost three complete virtual machines in the process, because these approaches turned out to be dead ends. I bet you'd need a lot of courage to explain this to a VC. ;-)

jhawk28 15y ago

I like a lot of things about CouchBase, but is it going to get the replication approach that CouchDB has? That is exactly what I am needing right now.

ultimatewarrior 15y ago

Something is wrong with both CouchDB and Damien

czue 15y ago

I found it surprising that Damien comes off so completely unapologetic about his decision to abandon Apache and the CouchDB community. As a long time CouchDB user and open source believer the whole tone of his post leaves a dirty taste in my mouth.

robterrell 15y ago

I've spent the past year building an app on CouchDB and I've really enjoyed using it. The couch.io to CouchBase transition was poorly communicated, so I'm glad Damien's made such a clear statement of intent. Clearly I'm going to have to stick with Apache CouchDB for now. I was interested in moving to CouchBase, but that's surprisingly difficult: 1. There's no easy transition for my data. I thought I could just install CouchBase and replicate from my existing CouchDB -- nope, can't be done. Huh? But why... 2. It's partly because CouchBase drops the CouchDB REST API. Which also means, none of my existing code works with it. So I guess it's no big deal that my data won't move over, because my app won't be able to retrieve it anyway. Because there's no easy transition, they've created a situation where anyone considering a move to CouchBase is just as likely to re-evaluate all of the other document (or k/v) stores.