бесплатный db2 может использовать только половину, а то и четверть современного процессора (2 ядра) и только 2Gb RAM, поэтому даже если опустить флейм версионник vs блокировочник все будет зависеть от железки. чем мощнее железка тем больше преимущества постгрес. db2 значительно лучше оптимизатор, но на сайтиках обычно запросы не слишком наворочены, поэтому наврядле даже в пределах 2Gb RAM у db2 будет значительное преимущество.

sanyock2 и в то же время использовать файловую систему с обильным кэшированием операций записи на сервере с большим объемом памяти (16 и более гиг), то как это повлияет на производительность DB2 Express C
тогда и многоблочное чтение придется отключать, но подозреваю, что оптимизатор такое не оценит, планы то он строит с учетом знаний сколько блоков таблицы у него в буферном. без многоблочного чтения, еще и с уверенностью, что придется читать с HDD думаю db2 начнет строить весьма загадочные планы ...

ЗЫ. вырубание буферного кеша к потерям данных не должно приводить.

sanyock2
к потере данных может привесьти выход из строя оборудования, в т.ч. резервного питания, при
кэшировании записи в файловых системах типа XFS, при объеме кэша >= объем БД
не может. Write Ahead Log для того собственно и создавался, пока запись не пройдет в лог, транзакция не закомититься. кеш ФС и буферный это совсем другая история, логу никаким боком.

sanyock2с другой стороны в такой конфигурации даже DB2 Express С наверно будет работать побыстрее, интересно насколько?
не факт. такой изврат мерить нужно. вообще мысль с PL/pgSQL была очень к месту (я всегда говорил даешь pl/sql стандарт вместо ansi каши), при таком расскладе когда бороться с извратом надоест - будет возможность перехать на взрослую редакцию оракла или db2 (если там миграшен кит действительно работает). хотя имхо такие вещи вешают на стандартный хостинг и не заморачиваются с лицензиями.