[onion2k]

It's often cheaper to use the "wrong" architecture than optimising the right architecture. I know I could have a CouchDB datastore searching a few GB with an afternoon of work. I imagine I could get MySQL fast enough with a few days of optimisation. In terms of time, which is by far the biggest cost in most development, CouchDB is the better option.

[personZ]

In terms of time, which is by far the biggest cost in most development, CouchDB is the better option.

For a single, one-off utility, sure. For anything that you ever planned for production, that would be crazy.

Just to be clear, the mentality that onion proposes (at least from my interpretation, though I apologize if I'm misunderstanding), usually justified under a gross misinterpretation of the "premature optimization" warning, is exactly how disaster implementations that end up failing or requiring enormous amounts of engineering time to try to triage and bandage into something usable.

[hcho]

At least for the startup world, it's about prioritisation of concerns. Will that disaster implementation take me to my next(or first) round of funding? If yes, I'll happily go with it. After that, I can throw money at the problem.

[sbov]

Disaster recovery is easy to put off forever because you don't need it until you do. When it happens it can also kill off your company.

I've been involved in companies that went 14 years without a disaster. Another company I was involved with had 2 in a span of 2 months, each taking between 2 and 3 days to recover from.

Regardless of whether I need it or not, I sleep better at night knowing a decent plan is in place. Which means I can perform better during the day.

[ulisesrmzroche]

Yeah, but was it your choice of DB that killed you or something else? That something else is always more likely to happen and more dangerous than 'oh noes all my data is gone stupid mongo/couch!' as if that ever really happens.

[sbov]

Granted, I was making some assumptions about the original post. For me it's not about the choice of DB, it's about having the proper knowledge, time, and team to be able to setup a production environment that isn't seriously flawed in one or more ways.

I would need a hell of a lot more than a time savings of 1-2 days to add a whole new database technology to my production environment. Even if I know the tech the installation, configuration, automated backups, and automated validation of backups will likely consume more than 1-2 days to get setup. Then add on the learning curve aspect if I've never used it in a real production environment. Then add on the learning curve for any team members who might not be familiar with it.

Weeks, maybe. A day or two: not worth it.

[ulisesrmzroche]

Well, what about other value besides time, which is pretty subjective to begin with, and it doesn't really matter anyway. Like maybe more robustness, bigger dev communities, one of your team members is an expert and can do this quickly, etc.

I think if your architecture is likely to collapse when you shop around for databases, then you built the whole thing wrong to begin with.

[ulisesrmzroche]

That's just like your opinion though. You ever used CouchDB in production before?

[personZ]

I passed zero judgment on CouchDB, but was responding specifically to the notion that doing something "wrong" if it saves you a small amount of development time at the outset is fine. When these are foundational things like your data tier, such an attitude is a primary ingredient in project failure.

[ulisesrmzroche]

Nah, dude, you're saying that it's ok for one-off projects, but you'd be crazy to use it in production because it's gonna blow up on your eventually. That's not true at all. Plus, ya'll arguing about conjectures with that catastrophic failure stuff.