Comment by jerrya | Hacker News Reader

Comment by jerrya | Hacker News Reader

I did find this point from the original article to be very dubious:

In fact, I would argue that starting with NoSQL because you think you might someday have enough traffic and scale to warrant it is a premature optimization, and as such, should be avoided by smaller and even medium sized organizations. You will have plenty of time to switch to NoSQL as and if it becomes helpful. Until that time, NoSQL is an expensive distraction you don’t need.

Consider:

- how hard most organizations find it to refactor, rewrite, retest, especially in systems that are online 24x7

- when would you prefer to climb the learning curve with an immature technology, when you are small and starting out, or when you are a large company with a large set of users and under "mission critical" constraints (and possibly stockholders and the like.)

My guess is that ongoing companies find it extremely difficult and expensive (and wanting for talent) to switch from one sql database to another, much less switch from sql to nosql.

It's not a matter of SQL vs. NoSQL. They are complementary.

The fact of the matter is, there are some components of systems for which Redis, Riak, etc may be better suited than SQL in the long term. Starting out, keeping everything in SQL provides less friction, but as time goes on it may be necessary to scale the component separately from typical relational data storage, and that's the point at which these switches are evaluated. These companies would be replacing SQL only in these components — not across the board.

The myth of a silver bullet datastore solution is just that: a myth. Different data stores have different strengths and weaknesses and it becomes necessary to mix and match at scale.

To quote Benjamin Black: "Scale is pain, princess. Anyone who tells you different is selling something."

You hit the nail right on the head.

When you're small and starting out is definitely not the time to be mucking around on a learning curve.

Learning a new tech in a startup is doing a lot of 'busy' work that is only beneficial to you as you're learning something, it doesn't benefit the business, it slows it down. You're also more likely to make fundamental mistakes in your implementation as you don't know the tech.

And switching when you're running is not as hard as you'd think as you already have the domain knowledge of how the solution actually needs to works.

It's all a balancing act, if the new tech is a fundamental selling point (for example your program's 10x faster than incumbents) I can understand it. If it's to deal with future scalability problems, well, that'll be a good problem to deal with later.

Reply on news.ycombinator.com