3 ms·
Exactly. This article typifies premature optimisation. If MongoDB lets you prototype faster, then use it until you have enough paying customers to warrant a ref
by izolate 9y ago
Exactly. This article typifies premature optimisation. If MongoDB lets you prototype faster, then use it until you have enough paying customers to warrant a refactor.
- StavrosK 9y agoI think you're greatly underestimating both the effort of changing a datastore from under a live application and the free time developers in a startup have.
- pandama 9y agoOh, wait. So you should actually think about what you're trying to build and what would work best for it? I just read this hilarious blog post that said the opposite. This is all too hard, I'll just use Postgres(R).
- StavrosK 9y agoBy "Said the oppposite" do you mean this part?: > Think before you pick a database. If you insist on not thinking, pick PostgreSQL. Trust me.
- deleted 9y ago[deleted]
- mannykannot 9y agoKnuth's aphorism on premature optimization is perhaps the most misunderstood point in software development. It applies to code-level algorithmic optimization, not architectural decisions, where a bad choice can lead down a very long dead-end. You can recover if you recognize this in time, but you are better of if you do not have to. Obligatory rewriting is not what you want to be doing just as competitors take notice of your initial success.
- notacoward 9y ago> If MongoDB lets you prototype faster Does it? Even a prototype involves some iteration, which can be derailed by the kind of missing-schema problems that the OP mentions. Throw in a few operational problems, and your prototype isn't really any faster than something with better features and reliability. What's better for that first few lines of code on your laptop might not even get you to a prototype.