> Just some warnings against mongo being a magic bullet:

> P.S. Does anyone really estimated how much will be losses in case of some
> (0.00...X) transactions lost due to lack of transactional support in mongo?
> I mean in stores like amazon - it's not a question, losses are huge, but
> in case of an ordinary e-shop? Are they really so big? One developer cost
> about 100 / per-year, so, mongo allows to build product faster and thus
> save cost on development time (although, it's also subject to question).
> The question is - what's higher - cost of development or lost transactions.

> I think there are reasons why mongo is useful, but saving on developer
> costs is not one of them.  When I hear people argue this position, they
> usually don't know much about mongo (and a lot of times aren't big on
> databases in general) and their hope is that they can build a web
> application without having to learn how their db works or how to administer
> it (or rather, learning mongo is much easier than learning mysql).  I'm not
> saying people are dumb for hoping this will work, but I do believe it's
> incorrect and is based more on PR than reality.  Having used both, my
> opinion is that all db's are complicated and it takes a fair amount of
> knowledge and effort to not screw it up when the stakes are high.  If you
> want to speed up development (regardless of db), you can outsource the db
> work for a while and get consultants to train you and help you set it up
> and use it properly.  

> though Mongo is not ACID .  however, when i raised that question to 10gen
> during a training, one of the solutions they suggest is to do it in code
> with two handshakes for committing data.  not pretty but dorable.

> This is total marketing FUD, Murvin I am glad you didn't buy it.  Any form
> of saying "just implement transactions yourself in your application" is
> pretty damning - that's a *huge* burden the db vendor has just foisted onto
> your dev team.  You are not going to be saving any developer cycles if you
> have to do that.

> I'm not saying "don't use mongo ever."  Just don't use mongo because you
> think it will be easier than mysql, especially if you need transactions
> (which you will if you are doing commerce).  And if you're building
> e-commerce and handling transactions and money, you should have staff
> dedicated to db operations and security very early on in your startup.  You
> can't measure how badly things will go if going got messed up, it's
> impossible to make a judgement like that ahead of time.  It's an important
> enough part of the system that things will move faster if you have someone
> handling it full time.

> Again, not anti-mongo, but I see a lot of dev's pinning their hopes on it
> being a magic pony (and a lot of marketing encouraging this), and it make
> me want to slap a big warning label on it.

> Maybe postgres + elastic search is what you are looking for?  It's a
> pretty winning combo if you're building a store.

> Ted