I think, in 2010, a "cloud-based web platform with a RESTful API" is 1990's "database." We don't let multiple applications talk to a single database; we stick a web server in front of the database and make them talk to that. If all the web API is doing is allowing CRUD on your data (with validation and some minimal triggered interactions) then, in effect, you're just creating your own, completely custom DBMS by doing this.
Yes, and this has a lot of advantages. One advantage is openness of APIs for mashups etc. But the big advantage driving the NoSQL/custom DB is of course scalability and performance. Incidentally performance was also a key consideration 40 years ago when everyone rolled their own custom data stores. The modern SQL database evolved as a response to all the problems that created, which by now are long forgotten.
My point is not to throw the baby out with the bathwater. If you need massive scale then of course you need fresh approaches, but you are sacrificing a lot by abandoning a centralized DB.
If your data is moderately sized, then you will be trading a lot of data integrity, queryability and flexibility by giving up an SQL databases. Certainly consumer web services of the type that are en vogue in silicon valley need new approaches. However the majority of applications out there are probably still best served primarily by a relational DB, especially when you consider the value of a byte of corporate data vs the value of a byte of facebook data.
in effect, you're just creating your own, completely custom DBMS by doing this.
I've argued for years that this is what the "sharding" hype (and to some degree the current NoSQL hype) was mostly about.
I'm not suggesting a custom DBMS can't possibly be the right answer, but it seems silly to layer it on top of something as heavyweight as a relational database.
If you don't use relational databases, you're throwing away decades of work into a problem that's very similar to the one you're trying to solve. If you have a brilliant new scheme that forces you to do that, fine, but throwing away finely tuned systems because complex and relatively opaque might not be the best first step.
