InfoWorld: Things Never To Do With A Relational Database
osintegrators.com
osintegrators.com
To take one example from there - storing images in your db - this might actually be fine if you have a cache in front of your app servers, since your db only takes the hit once and then nginx/varnish serves the request after that.
Doing replication, versioning and backup for postgresql across a bunch of app servers is fairly straightforward. If all of a sudden you're doing it for postgresql AND mongodb AND lucene - and keeping all those backups in sync with each other - it gets a lot harder, at least without downtime.
Nosql, lucene etc are great tools, but often they're premature optimization. Make it work first using the simplest tools you have, then add complexity to improve performance only where and when required.
Secondly, prototyping your straight JQuery/HTML to MongoDB or Couchbase 2.0 is SIMPLER than to the RDBMS where you must do XML transform first.
Search in RDBMS with ORs and LIKEs is hard and not a good idea for the RDBMS or your middle tier or your user (reduced capabilities with more complexity).
Storing images in the DB vs say a clustered FS makes everything from replication to performance to scalability. Get a few TB of BLOBs and tell me this is a good idea.
Ending up with a dynamically generated query which got really long depending on how many spaces you entered... smh