In our article The Pure Relational database is dead there were a lot of misunderstandings as a result of our poor choice of words. People thought we were bashing the relational model because in their mind that was what pure meant. I got hit with a lot of poetic insults. I still can't think of an alternative word to use for what I meant. Simple doesn't really do it as even relational databases with just standard types were far from simple when you consider the planner and all the other stuff going on under the hood to protect you from the underlying storage structure. What I was trying to say is that in the beginning most relational databases just supported a standard set of types which you could not expand on and most people when they think relational today still think just that. That type of relational database is in my book dead or almost dead.
How did this all start. Well whenever we use something like PostgreSQL to store anything complex -- take your pick: geometry data, tree like structures which we use ltree for, full-text query constructs, and Yes XML we get bashed by some know-it-all who has a very narrow view of what a relational database should be doing and suggesting we use a NoSQL database, a graph engine or a full text engine or normalize our data more. I have also learned XML is a dirty word to many people. I mistakenly thought XML was a complex type people could relate to, but turns out they can relate to it so well that it brings up tragic memories I can only equate to Post Traumatic Stress Disorder suffered by war veterans or (early or wrong) technology adopters. That was not my intent either. XML was just merely an example. I will not say you should use XML in your tables, but I will also not say you should stay clear of it as many people wanted me to say. I will say its use is rare, but it has its place. It has its place just as any other complex type and it has its own special needs for navigation, indexing etc. which many relational databases handle fine enough.
My point was that the relational model, SQL, complex types, and user defined types work handsomely together. If you look at Oracle, DB2, PostgreSQL, SQL Server you'll see they have made lots of enhancements over the years to beef up their indexing, storage etc, so that YES your specialty types get treated with the same care that they provide for their more standard packaged types. That means you can write SQL that say outputs a geometry, a person's name, or a subset of data from an XML field and that can navigate data with a simple btree join or an RTree based join and then on top of that do further filtering using specialty functions many of which can also make use of specialty indexes or to output a subset of data of a larger object. This combination in my book is much more powerful than creating a separate database to for example store just graphs, or full text engine, or navigable documents. The reality is that related data comes in all shapes and forms and can be related to other data in a different shape and form. It is rare that a document storage proposed by JSON (Couch Db, MongDB etc.) is ideal for all your data just as it is rare that all your data should be finely normalized and broken up into columns with a canned set of types we are used to working with.
I am not bashing the NoSQL folks by any means. If all you want to do is that, then I'm all for simplicity and simplicity is best if it satisfies all or most of your needs or is significantly faster. For my apps however I need something a little more that can handle all my specialty needs. My needs for navigating across space, across nested relationships, and every so often querying an arbitrary bag of properties (e.g hstore, json, xml) without having to join with many more tables, and even use a more suitable syntax such as the syntax for querying full text data. This is why I choose PostgreSQL, because it lets me do all of that and lets me do it with my favorite language SQL and most of the time with a single SQL statement. Also please stop with these arguments about how SQL does not mean Relational and not what Codd had intended. I know all of that, but I still like it never the less and whether you like it or not, the databases we classify as relational HAVE standardized on SQL and SQL ain't a naughty word.