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.

I would imagine, though, that companies that are "on their game" enough to become big are probably also the kind of company that will realize that they are now being burned on per-transaction costs rather than fixed overhead, and have the wherewithal to spend the week required to recorde their backend for a different API. Some companies won't get around to it quickly (after all: successful companies are busy), but that still seems like an awkward thing to rely on.

So, on that note, have you thought about setting up fees that scale better for larger companies? If you are doing two million dollars a year, PayPal's fees (for an example; PayPal is even a little more expensive than most processors, but are simply so far reaching it is hard to avoid them) will have dropped to 1.9% from 2.9%, saving $1666/month; at $10 million a year, this is enough for a reasonably high quality full-time employee.

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

> 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.

In that case, I would think that the indexing stuff (i.e. hash lookups) would be way better than linear already. Cool.

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.