The time for NoSQL is now, cue Oracle's 15 year decline
In 1998 I had my first hardcore introduction to Oracle as well as HP/UX. I'd been working with SQL Server. I thought Oracle was magical. Unlike SQL Server there were so many knobs to turn! I could balance the crap out of the table spaces and rollback segments and temp segments. Nothing would ever have to be contending for IO on the same disk again (if only someone would buy enough disks)! HP/UX oddly led me to Linux. I had a graphical workstation and a Windows machine on my desk. The graphical workstation rarely remained in working order. A co-worker who had quit Red Hat, (before the IPO!) to join me at Ericsson USA, introduced me to Red Hat Linux 5.0. The great thing about it was that the X-Windows implementation allowed me to connect to the HP/UX box's X-Windows with no problems. Eventually, I came to prefer Unix and Linux to Windows because they never seemed to crash and on relatively old hardware they performed better.
At some point, due to turnover, I became the final person around who knew how to care and feed Oracle. I knew what all the mystical ORA- numbers meant. Oracle was far better/faster for reporting than SQL Server. However, in normal business applications, not only was SQL Server cheaper but it didn't need constant attention, care and feeding. Over the next 10 years, I watched the industry homogenize. Sure, SQL Server is around and far better than the one I used, but every large company I've worked with has an Oracle site license. Even the "Microsoft Shop" tends to have Oracle around for the big stuff.
I've made hundreds of thousands if not a million dollars tuning Oracle, caring for Oracle and scaling Oracle. I've written ETL processes, I've tuned queries, I've done PL/SQL procedures that call into other systems and even into caches to squeak a little more performance. I've scaled systems with millions of users on Oracle. The trouble with Oracle is that it is both frequently misused and that it really isn't very scalable. I'm not saying to can't make it scale, just saying it is expensive to do (the license costs are the tip of the iceberg) and that it is difficult work to do so.
The problem is not transactions so much as the relational model combined with the process model. You can work around these with flatter table structures and by using different instances for different data (think of the lines for voting A-N, O-R, S-Z), but that is work! Oracle RAC sorta makes things better on the read side, but with all new headaches and often with worse write performance. You can add a cache like Gemfire or Infinispan and indeed these are good solutions for the interim where you can't fix the Oracle. However, fundamentally you're trying to fix a broken foundation with struts and support beams. You can shift the weight, but really you're not addressing the actual problem.
NoSQL databases, especially document databases like MongoDB or Couch, structure the data the way your system uses it. They shard the data automatically, they store your actual JSON structure without all of the transformation like Hibernate or JPA. The less transformation the better the performance of the system, the more automatic the scalability concerns, the fewer bugs! I don't usually jump on bandwagons: the new language of the week (all compile to the same thing, none have significant productivity gains when you have a team size of more than say 2), whooo touchpads (I want a keyboard), filesystem of the day (I kept ext3 until I switched to an SSD drive), however, this particular bandwagon truly is a game-changer and completely necessary for cloud/Internet scale applications.
Yes SQL databases are completely fine for a departmental IT system. While Open Software Integrators does a lot of varied work with applications that don't need to handle 8 million users, I don't personally work on those applications. Most of the systems I work on are at least dealing with thousands to hundreds of thousands and in some cases millions of users. In the end, applications almost always bottleneck on the DB and most of what I do for customers is actually DB consulting in the end. The transition to NoSQL databases will take time. We still don't have TOAD, Crystal Reports, query language standardization and other essential tools needed for mass adoption. There will be missteps (i.e. I may need a different type of database for reporting than for my operational system), but I truly think this is one technology that isn't just marketing.