One of the pleasures in the life of a database consultant is to be able to tell a client that they don't need a relational database at all. Plenty of scientific applications don't need them nor do many social media or recreational applications. You are often much better off with a system that specializes purely in the requirements you have.
There are, of course, problems with this. You have to know your requirements in detail up-front. Sometimes, the team who are designing and building an application don't know, or have never thought about, the broad scope of their requirements in detail. They become excited by the speed at which a particular database system stores and retrieves object data, and make a quick gut-decision to use it. Only later do they realize that it is almost impossible to restore a backup, or that the data can be read via an 'exploit'. There have been several disasters where trading systems built on NoSQL have failed to realize the importance of transactionality.
The confusion happens because there is only one word in the industry to describe a database. Many of us use the term casually to describe any system that allows you to store and fetch data. The term 'database' comes with baggage, though. There is a general understanding that a database will allow more than one process to access the system simultaneously, can cope with recovery (Backup/Restore), security (is it possible to hack the data), access control (do users see just the data that is appropriate for them), transactionality (will it handle business transactions safely), isolation, resilience and performance. We can sometimes assume that anything that calls itself a database has all these qualities and it can come as an unexpected, unpleasant and expensive shock when it doesn't.
A relational database is a safe bet, particularly where you're not yet clear about your requirements. Now that they are offering in-memory optimization for tables, it is an even easier choice. If you run out of grunt with a relational database, it is usually for the happiest of reasons: your application is so popular that it needs a distributed architecture. Even then, you have an easy migration path. You can delegate much of your ETL, archiving and specialized processing to a NoSQL database such as Couchbase, or migrate to a hybrid system such as VoltDB.
What am I saying? Could it be that a relational database is so versatile and feature-rich that it is the ideal database for an Agile development? Certainly, it is safe to say that you need to have done plenty of architectural planning to be confident enough to select a NoSQL alternative that matches the requirements and priorities of your applications.
Phil Factor.
