Promoting Couch-DB to management

Question

I've run a series of somewhat brutal tests against CouchDB 0.10 and it handled itself well (ex. the server's netstack caved in but best I can tell CouchDB was still functioning ). Unfortunately none of that really matters if I can't convince clients and employers to allow me to use it*.

Common fears I've heard.

1. "It's only Version .10, thats not even a production release!!!"

2. "But [MySQL|PostGres|Oracle] works fine for [object metadata storage|literal "document" storage|etc]!"

3. "This seems overly complicated ( map reduce based queries, REST api, JSON, etc ) compared to XYZ."

4. "What the hell is an erlang?"

*Normally my rule is to tell the client I will solve the problem, but not go into detail. Unfortunately some client's fancy themselves as back seat architects/engineers or are rightfully wanting to be informed.

**Pre-emptively arguing this is programming related because sometimes it doesn't matter how much better a tool is if management can't/won't see the benefit over risk of stepping outside what is known.

Answer 1

Why not take another DB which does roughly the same but is more tested like mongodb?

Extra benefit: it's not in erlang, so it's already fast when only 1 core machine is used. (Apparently erlang starts to shine after 16 or 32 cores)

Answer 2

Although certainly hard to answer, I'd approach this topic by asking myself what I needed to hear if I had to decide. What factors would be important ( reliability, perfomance, cost ) and what factors aren't?

I guess everyone doing the stuff we do is sooner or later confronted with people who are .. backseat programmers, know everything better etc., but one should never let micromanagement and "supposed knowledge" alter a decision based on hard facts ( like your tests ).

Answer 3

G'day,

Have you bounced this question off the CouchDB community over at the CouchDB site?

Though I'm a lurker because of my interest in Erlang, they seem quite an active bunch.

Edit: Ooh. I was just having a browse through the rough cut of the new O'Reilly CouchDB book and there's an excellent chapter available called "Why CouchDB?" that's got some great info in it. Might be worth a read.

N.B. As O'Reilly say on their website "This book is a work in progress." so don't be surprised if there are typos or grammatical errors. (-:

HTH

Answer 4

I think the client has a set of valid questions and fears. Simply running a set of tests against a database is no guarantee that

a) There are not bugs in the code that will be revealed over time. Have you ensured every function in every piece of code has been tested? Have you run every possible query? Even Microsoft and IBM, with access to their own source code, huge teams of testers, still have bugs in their software. What makes you think you can guarantee no bugs in the code?

b) Software that has been used by more users does have a better chance of having fewer bugs. That's the idea behind beta testing. But, having a huge user base is even better. So, their question about using PostGres/etc is a valid one.

c) They're saying KISS - that's also a valid question. You should be able to answer it.

d) What the hell is erlang - again, you should be able to answer it.

Software is like justice - it's not enough just to be reliable, it is also necessary to be perceived to be reliable. That's part of your job. The user is trying to manage his risk. If you can't answer these questions, then why should he trust your software?

Answer 5

Some years ago I had the same problem trying to convince customers to use python + postgreSQL for the web instead of asp, php, or whatever.

What worked for me, besides explaining the technical advantages, was adding some success stories.

In CouchDB case you might cite:

• BBC: Erlang at the BBC
• Meebo http://code.google.com/p/couchdb-lounge/
• Ubuntu: Ubuntu One
• Mozilla

In this presentation there's a slide citing other companies.

Answer 6

1) 1.0 is suppose to be wrapped up in the next few months to resolve the exact issues you're running in to with people not thinking the current version is up to snuff.

2) while map/reduce might be slightly more complicated than SQL you can do much more complicated indexing across different kinds of dataset without all the table relation crap you have to do in RDBMS. Also, that's just the indexing part, getting data in to CouchDB couldn't be easier, get it in to JSON, push it over HTTP, done!

Most of the times that I've "convinced" people to use CouchDB I've just showed them something that we need to do that isn't feasible with RDBMS.

The most compelling thing for me has continued to be how easy it is to just get data in to CouchDB. This doesn't make any of our efforts block while we're coming up with schema and tweaking the ORM and all that, we just shove data in right away and add indexes as we need them, it's a much more productive cycle.

Answer 7

One of my favourite illustrations of the KISS principle behind CouchDB that goes well with "are all code paths tested" is that CouchDB is roughly 15k lines of code while ActiveRecord, Rails' ORM is ~25k LoC (last time I checked) just to make an RDBMS talk to an OO language. While this is clearly comparing apples and bungalows, it should show that CouchDB itself is relatively simple and has manageable code size. (All this matters because the number of bugs per lines of code is constant)

Another plus for CouchDB is it being an Apache project. It ensures a stable community (not necessarily software :) and longevity, which can be important to know before pouring money on a project that will be used for a number of years.

@renier what makes you think MongoDB is better tested? Also, Erlang is awesome on a single core and it doesn't get lame at 2, 4 or more. It's not that you only reap it's benefits when using a single cpu. Erlang's design principles enable software that runs 24/7 to the point where operations staff forgets how to troubleshoot an app because it never breaks (there is a British Telecom study backing this up, it also mentions the famous nine-nines availability).

Answer 8

I think i can answer your questions and give some pros for couchdb.

1. The version says only that there is planned a lot of work til version 1.0 not that it is in a experimental or not robust state.

2. It is even more simpler than other ORDBs, communicates over HTTP and so it needs no other Backend technology like all other web application approaches. This safes time and effort and has a lot of advantages at scaling, performance and relaibility.

3. Erlang is a new programming language developed by motorola to solve some issues like fail tolerance, etc. of current programming languages like C#, Java, etc. Damien Katz build Couchdb in Erlang.

There is a book online available describing couchdb at http://books.couchdb.org/relax/intro/why-couchdb

simply, it is a paradigm change

Answer 9

If there were tried-and-true solutions available, I would not entrust my business to a product that is not yet at production stage, whose long-term viability is still open to doubt, and where programmers who know the product and related languages may be relatively few and far between, and where there are relatively few support resources available. I would not entrust my business even to an established product if it had skimpy market share. I've been a manager at a company that used an established, stable, excellent product which had only a sliver of the database market; finding competent programmers was difficult. While a product's unique features might yield an application with a significantly lower cost of acquisition, a newcomer's position in the marketplace, or a small market-share position even if the product is not a newcomer, can result in an application with a much higher cost of ownership over the long term. Not being able to find talent can also hamper a company that is trying to respond quickly to change or new demands. The number of lines required to produce functionality X is an irrelevant metric when the number of programmers who know the language well is relatively small. These concerns can beset even a stable platform. Add a rapidly evolving platform into the mix of risks and it just seems imprudent to choose such a product. But I might consider it for something that was not mission critical and had no chance of becoming mission critical, assuming I had a budget for experimentation and "R&D".