In the thicket - the pros and cons of different database technologies for different projects

"Daddy, where do products come from?"

Well, someone sitting in a coffee shop has an idea, and then this happens, and then that happens, and then some developer in Palo Alto or Portland or Rancho Cucamonga or Delhi has to choose a database technology.

Eddie Awad recently shared a paper by Michael Rhys entitled Scalable SQL. If the product has a huge database, then some things need to be considered. For example, maybe SQL shouldn't be used at all:

One of the leading motivators for NoSQL innovation is the desire to achieve very high scalability to handle the vagaries of Internet-size workloads....

The main goal of the NoSQL/big data movement is to achieve agility. Among the variety of agility dimensions—such as model agility (ease and speed of changing data models), operational agility (ease and speed of changing operational aspects), and programming agility (ease and speed of application development)—one of the most important is the ability to quickly and seamlessly scale an application to accommodate large amounts of data, users, and connections.

At the same time, Rhys notes that many companies that manage big data have actually chosen SQL solutions, rather than NoSQL solutions.

Now I certainly can't comment on the technical details, but Alex Popescu has shared this observation:

[U]sing NoSQL solutions involves an incremental approach where you create and assemble together the building blocks fulfilling the requirements of the system, while using a relational database translates the set of requirements into solutions to overcome/eliminate limitations of the database.

Of course, the two approaches also may (or may not) have implications for the way in which the solution is developed, but that's a whole other issue.