Московская биржа выбирает Linux

Если CentOS и Red Hat объединились,то о каком паразитизме реч ?

Чой это? MySQL самая быстрая СУБД. Правда, больше заточена под Web.

Да ладно. Для начала у MySQL нет параметрических запросов. Я же пояснил.
Максимум где можно ускорить MySQL это передать в одном insert сразу несколько значений для добавления, но при этом размер запроса будет ограничен max_allowed_packet. И если надо добавить несколько тысяч записей, это станет проблемой, необходимо писать скрипт для разбиения запроса на кусочки. В IB/FB можно создать параметрический запрос на insert и потом просто гнать в него только данные. Что касается update и, в меньшей степени, delete, то тут в MySQL вообще ничего не ускорить, только слать полностью текст запроса, который сервер каждый раз будет компилировать. И это не считая того, что таким образом приходится бороться с инъекциями. В IB/FB в параметрических запросах такой проблемы не существует в принципе. Для MySQL возможна только имитация параметрического запроса, что и делается некоторыми фреймворками (от DQE до Yii), но скорости это не добавляет.
Что касается PosgreSQL, я с нем работал очень мало, но скорее всего у него есть параметрические запросы на уровне СУБД как и в IB/FB.
Про заточку под web: и в чем она заключается? У MySQL, PSQL, IB/FB нет никаких web-спецефичных функций. Просто их берут и используют под Web.
Про кэширование запросов в MySQL: функция приятная, но к сожалению кэшируются только статические запросы т.к. у MySQL нет параметрических запросов. В связи с этим диапазон применений кэширования не такой уж и большой. Реализовать кэширование в FB на уровне фреймворка/приложения не так уж и сложно. Можно считать crc/sha контрольные суммы текста запроса и сохранять в таблице вместе с результатом. При некотором желании можно сделать кэширование и параметрических запросов.
В MySQL невозможно управлять планом выполнения запроса в FB можно. Бывают случаи, когда изменение плана приводит к существенному росту производительности. Часто это заметно, когда одни из таблиц имеет несколько тысяч (а то и десятков и сотен тысяч) записей, а связанная с ней — несколько сотен и результат получается относительно небольшой.
Про бесплатность: права на MySQL и PSQL принадлежат коммерческим конторам, которые в любой момент могут выпустить версии, лишив их GPL и преценденты есть, тот же Borland Interbase. FB изначально отпочковался от бесплатной IB (которую в следующей версии опять закрыли) и развивается как свободная система. От него можно только сделать свой форк и тогда попытаться сделать его платным, но сам FB останется свободным ПО.
Про фрагментацию БД: да у IB/FB есть такая проблема. Более того, сам файл БД при частом изменении метаданных часто приходит в такое состояние, что БД становится поврежденной. Что бы этого не происходило, необходимо как можно чаще пересоздавать БД. Особенно после операций ALTER, особенно тех, при которых менялись типы полей и ограничения на них типа "NOT NULL", "FOREIGN KEY". Пересоздание БД на лету невозможно, приходится отключать все соединения. Это издержки однофайлового СУБД (знаю, что можно несколько файлов, но по сути это один файл, порезаный по нескольким). Но есть и плюсы. Можно создать ramfs и нужную БД положить на ram-диск. MySQL или PSQL такое позволят? Они позволят положить все БД на ramfs, но не одну выбранную. Создание memory table это все-таки работа на уровне структуры БД, а не на уровне конфигурации сервера.
Отсутствие полнотекстовых индексов — да минус, но как всегда есть варианты. И опять же параметрические запросы помогут.
Так что в целом потенциал роста производительности в FB будет повыше, чем в MySQL. Надо только уметь пользоваться FB. Оно и понятно. MySQL изначально создавалась как простой (в реализации) и маленький СУБД. По сути он таковым и остается, хоть его код и разросся до приличных размеров, превысив размер FB. Но надо признать, что MySQL при этом активно наращивает количество инструментов и по идее поддерживает весьма широкий набор типов данных, таблиц, фич. Для FB было бы неплохо поддерживать такой набор. В целом для прототипирования MySQL подходит лучше, чем FB. FB скорее подходит для создания конечного продукта.

Кто бы спорил. Беда в том, что свободные дистрибутивы Линукс говённого качества. То звук, то негодные драйвера на видеокарту, то процессор греется.