Scalable in which way? Horizontal or vertical? NoSQL DBs scale well horizontally, while RDBMS (SQL DBs) are scaled vertically.

Horizontal scaling (scaling out) means adding more nodes (machines) on which the data is partitioned. This can practically happen unlimited.

Vertical scaling (scaling up) means spreading the load between CPU and RAM on a single server (or a small group of servers), i.e., adding more power. There’s a practical upper limit to this.

There is no definite answer to your question. Both techniques involve trade-offs, for example in form of setup, management and maintenance costs, and complexity, availability, etc.

I would take the right one for the definitions I get ;) ... as everyone should ...

If I need a MVCC I will take SQL and if I need certain behaviours I will pick the engine.

If I need documents I will use a document based storage system like mongodb, raven or others

If I need a http based database that works functional so I can build a distributed webapp with high concurrency maybe I take couchdb.

If I need a timeline or to get and find connections between things I will take a graph based database.

If I have a lot of data where some entites have data and some don't I will take a column based system.

Every engine and system comes with a price and you have to understand what you're doing.

I will ignore big data like redshift.

Instagram is pgsql, Uber swichted from pgsql to mysql because of the key systems, craigslist uses mongodb, facebook cassandra, .....

there is no real "noSQL" because noSQL != noSQL .... it's a twitter hashtag to my knowledge.

Table-, Graph-, Column-, key-value-, document-, object-based ....

So the starting point is in 90% what tech do you know .... and you grow from there and every religious nut telling you why his tech is the best is probably just ignorant ....

[Edit:] as pointed out it was misspelled (MVVC) this is not an behaviour bound to SQL every major database supports MVCC. The main difference is that SQL tends to prefer consistency over everything. so if there are two concurrent Statements the second one will for sure fail.

I just used it to bring in the broader perspective of what could be used for a decision. This whole list are just random examples which can be represented with almost any other database .... take what you need ...

There's an interesting trend in microservices where there isn't necessarily a single choice. To scale, you may have a SQL database for a subsection of your application, and a NoSQL database for another subsection. To me, this gets very complex, but there's merit to it. One of the benefits is scalability on a fairly massive scale.

The DB holy grail is one of my favourite things to talk about. There isn't a single correct answer here, it depends entirely on your requirements. It's really about horses for courses.

First things first, is your data relational? If yes, go the RDBMS way. I just love the discipline that a RDBMS store enforces - foreign keys and not nulls for examples.

NOSQL gives you a lot of power (in the sense that, there are not really a lot of constraints from I've seen), so it's easy to get sloppy. Use it only if you understand it.

But, like Joe said, most companies these days usually have a combination of a SQL store and a NO-SQL store. At my previous job, the 80% of the data was in Postgres and the rest was in Mongo.

I would say: are we (including myself) able to really understand this type of softwares (let's call them DataBaseManagementSystems) really in detail? so we can really evaluate them for design choices, knowing how to implement a design choice? I would say that knowing them is really difficult given the complexities they embed (DataBaseManagementSystems are really complex softwares). To be more specific I say something like having the entire source-code of something in mind when using it so you really should have an understanding of its behaviors (of course understanding the source-code is a part of the understanding because this knowledge has to be applied, and there are other elements in the system because the software does not run isolated, but it is part of a system that includes it).