[flukus]

It makes sense as a default because it will be the correct choice 99% of the time. Even when no-SQL is the better option it tends to be a better option for only part of the application.

Picking it as the default would make us wrong less often.

[seangrogg]

I question whether it's the "correct choice 99% of the time" or if, anecdotally, you're making the same kind of application and using technology you're comfortable with rather than considering alternatives.

[flukus]

> you're making the same kind of application and using technology you're comfortable with

To an extent yes, most apps (the ones that need a database anyway) are data oriented at their core, just a combination if input, storage and display. The data gets input here, it goes into rows, it gets displayed mixed with other data and displayed to someone else over there. Even when the specifics differ the data generally follows the same sorts of patterns because data is naturally relational and the combination of tables/rows/joins works really well nearly all the time.

> rather than considering alternatives.

The thing is, when you consider alternative you also have to consider the huge risks of what you don't know about them too. I've worked on one product where no-SQL seemed like the right choice, it was document oriented rather than the usual data oriented and it worked really well in our proof of concept. Problem is that the more we fleshed things out the more and more normal relational data we had and no-sql was making things more and more difficult and we started wishing we'd just stored the documents as a blob in an sql database.

So no, it's not just because I'm comfortable with it (although going with what you know has it's own merits), it really is the superior solution most of the time.