Long-running performance (MVCC, Vacuum, etc.) - Any fix?

I'm building an appliance where I don't want my customers having to 
tune postgresql in any way from the configuration when I install it. I 
don't even want them to know it is there. Yet in my study of posgresql, 
it seems that even conscientious use of a vacuum daemon or cron job in 
vacuum's various forms leaves databases after a while much larger and 
lower performing than the actual space and performance after a 
dump/restore.

It seems to me that with MVCC, an UPDATE (for example) is really a 
DELETE+INSERT and it takes VACUUM to mark the old DELETED row as free 
space again. So changing one boolean or increasing one counter in a row 
of 100 bytes will relocate this row in a different location. While this 
in itself isn't terrible as some DB page is dirty no matter what, 
unless I'm lucky enough to insert into the same page that changed, my 
index(es) for this table will have to be changed and this will dirty 
yet another page that wouldn't be dirty without MVCC. And this is not 
to mention the resources required by VACUUM. And the disk bloat over 
time would imply that postgresql doesn't always efficiently use 
free-space with records/rows of similar size and so performance 
degrades as there are fewer rows per page over time.

My application is multi-threaded and I could care less about the 
concurrency afforded by MVCC. I'd rather just update the things in 
place and get less postgresql concurrency but more consistent 
long-running performance and disk space utilization.

Is my interpretation correct?
Is there a way to turn off MVCC?
Do fixed sized rows help any?
Is there anybody using this thing in an appliance type application?
I'm quite far along with stored-procedures and whatnot, but if 
postgresql really isn't the right solution due to these reasons, I'm 
curious if anybody has alternate OpenSource suggestions? (I'm actually 
migrating from sleepycat bsddb at the moment because I didn't realize 
the licensing costs involved there. My needs really aren't that 
extensive really - a few associative indexes, cascading delete, etc.)


My large data sets will have the following characteristics:
5,000,000 Rows x 50 bytes/row (could be fixed) w/1 multi-column index, 
1 single-column timestamp index AT 1,000,000 index searches, 300,000 
reads, 150,000 updates per day
720,000 Rows x 32 bytes/row fixed w/ 1 multi-column index, 1 
single-column timestamp index AT 150,000 index search, 150,000 updates, 
100s of reads per day
2,000,000 Rows x 4000 bytes avg/row AT 100,000 inserts per day, 150,000 
reads per day

Thanks,
Eric

Eric Brown
408-571-6341
www.propel.com