You can do some incredible things with SQL. It's a very full and complex language, and relational databases are venerable and well-tuned. There's a movement called NoSQL which argues that relational databases aren't appropriate for all problem domains, and that other database paradigms should be considered in any problem.
NoSQL focuses on key/value databases -- not strictly; you get graph dbs and even XPath query DBs, but most of these "distributed" DBs boil down to key/value DBs -- since that's what most of the proponents are. I haven't yet encountered a NoSQL advocate who recomments an OODB, for instance. They're all about Hadoop, Riak, CouchDB, HBase, and BigTable (although, there are more). I suspect that this is because Google gave these DBs a lot of credence when it was exposed that they weren't storing their data in a SQL database. OODBs never had such a persuasive validation, and consequently are much more rare.
Non-relational DBs appeal to me. For one thing, they are schema-less. Relational DBs are in the "zone of pain" -- this is the zone of things upon which there are lots of dependencies, and yet are concrete objects (and so require changes as software is developed). Things which have a lot of dependencies are very costly to change, which is why you want as many of these objects as possible to be abstract (interfaces) -- but DBs are concrete, which means that they **will** change as the software grows. The alternative is that software developers tie themselves into knots, and implement all sorts of shady coding, to avoid changing the DB schema. If you dispense with the schema, then the DB is no longer difficult to change -- because there **is** nothing to change. It takes DBs out of the zone of pain.
For a second thing, SQL is usually overkill. And, when it isn't, the schema is usually so baroque that nobody understands it. I worked on a project at the US Forest Service where the schema diagram, printed, was 15 feet long and 4 feet high, and printed in a barely readable font. It was utterly unnavigable. I don't know if one of the NoSQL databases would have been a better fit in *that* case, but I'd have liked to have found out. Except, there wasn't a NoSQL movement back then.
In any case, I found the following reading interesting: