thegdb

It is likely we will add volume-based discounts in the future.

A company for whom $130 is significant today is not necessarily a company for whom $130 is significant tomorrow. One thing we want to do is lower the barrier to people trying out their ideas, and for those ideas that turn out well we've gained a large customer. For those that don't go well we (and our user) basically break even.

And as well as being a home for the casual weekend project, we have a number of users processing millions of dollars a year.

> While this is a very nifty bit of code, I'd be very careful about using it for unit testing as there is a high likelihood of minor behavior differences verses a real mongod which can cause surprises in production.

Yep, that's a valid point. My plan is to run my tests most of the time with embedded-mongo, and run against real mongo on occasion (such as say, using embedded-mongo while developing locally and real mongo before pushing to production). I haven't benchmarked it yet, but my test suite seems to run a lot faster with embedded-mongo than real mongo. And it's definitely a lot less work to use than an ad-hoc mock layer.

> PS- That is really impressive for a weekend project! You should get in touch with us at 10gen if you're looking for a new job.

Thanks! If my current startup goes down in flames, I'll be sure to give you a call :).

Thanks. Re: indexes - patches welcome :). I don't expect them to be hard to build though. Since embedded-mongo is in memory, they're just a bunch of hash tables.

One really nice part about the implementation was I could just reuse the Ruby Mongo driver's test suite.

Good point! I'll add that info.