And you are here why?

“Vacuum Stories” are pretty much a rite of passage for Postgres Peoples. Mind you, we don’t automatically flinch anymore when you whisper ”VACUUM” into our ears, but it’s still not an automagic thing — You really need to know what’s going on under the hood if you’re doing anything beyond the basics (•) The underlying issue in Postgres is that when a row needs to be updated, 1. A new version is created that is visible only to the transaction that created it 2. Once the transaction commits, the new row is visible to all subsequent transactions 3. Existing transactions will continue to see the old row 4. When there are no more “existing” transactions, the old row is deleted The ensuing space-management issues are the proximate cause for most of the vacuum stories out there, and  is based on the way Postgres implements MVCC . PostgreSQL’s approach to this problem is to store new row versions created by UPDATE in basically the same way that it would store a completely ...

John Wood (of Signal fame) has a post up about Signal's experience moving to, and away from, CouchDB.  Its an interesting real-world example of what I've described in " NoSQL - What you'll find (for sure!) ".  To recap, when first getting into NoSQL, you are sure to find that You didn't understand your own problem-space as well as you thought you did.  You didn't understand the package that you are using as well as you think you do. It will not  scale the way you thought it would.  Oh, it'll scale all right, just not the way you thought it would.  Your object/document/JSON/whatever model really doesn't map exactly the way you expected it to. In John's case, they found that HTTP is a Very Slow Database Protocol MVCC Overhead (is bad) Large Databases Beat Up the Hard Disk CouchDB is not a Distributed Database (by default) map/reduce takes a while to get used to Views take forever to build Views are gigantic on disk Replicati...