Yo.!возьмите mysql, уже от примитивного mysql отставания 5-8 лет по принципиальным вещам. и с каждым годом отставание увеличивается по экспоненте. во первыхЕсли упомянуто экспоненциальное отставание, то надо бы конкретику привести. Отставание в чём ? В соблюдении стандарта, в развитости SQL или процедурного языка, в управляемости транзакциями, в производительности ?
Стандарт SQL в ФБ стараются соблюсти во всём, щепетильность там даже чрезмерная (имхо).
Насчет возможностей SQL, который реализован в ФБ, - устраивает всё, за исключением отсутствия до сих пор оконных функций. Они будут только в трёшке, увы.
Процедурный язык выше всяких похвал ввиду его понятности. Синтаксис запоминается очень быстро, это почти "псевдокод".
Кроме того, он весьма шустрый, что часто провоцирует писать на нём, а не на SQL. Наконец, ранняя проверка валидности объектов (при компиляции) избавит от головной боли в рантайме.

Управляемость транзакциями - выше всяких похвал. Только в ФБ можно в одном коннекте открыть несколько транзакций и данные, записываемые ими в GTT, будут изолированы. Только в ФБ можно открыть read_only транзакцию, но при этом проводить запись в GTT (а это уменьшает объем мусора).
Совершенно несложно добиться мгновенной (или по разумному таймауту) выдачи сообщения об ошибке при попытке insert'a дублир. ключа в двух и более коннектах (вместо бесконечного ожидания).
Насчет производительности - сравнивать надо. С выводом настроечных параметров., разумеется.

Yo.!архитектурный мегобаг со стабильностью курсораХоть это и неприятная фича, но обойти её совершенно несложно, пусть и применяя процедурный подход (вытянув сначала все записи, подлежащие DML-обработке, селектом, а затем обрабатывая их по-одиночке в цикле). В форуме (bid=2) вопросы на эту тему весьма редки. Не так уж часто внутри курсора, сформированного выборкой с критерием отбора по полю F01, меняют именно это поле F01 (или вызывают DELETE с проверкой (не)существования других записей и также включают туда это же поле).
Мегобагом это назвать сложно. Иначе бы вопли шли со всех сторон.
Куда чаще спрашивают, как перекомпилировать ХП на продакшене при подключенных юзерах :-)
Yo.!уже которое десятилетие в это тычат firebird но воз и ныне там.Воз сдвинулся, кстати. Открыт "интегральный тикет ", в котором собраны все такие артефакты. И насколько могу понять, в ФБ 3.x этого уже не будет.
Yo.!дальше уже лет пять как наступил век многоядерных компов, firebird до сих пор толком SMP не имеет.Что оно даст, если большинство операций всё равно завязано на скорость дисковой подсистемы. Распределенные вычисления, что ли, проводить на ФБ ? Если же речь идёт о параллельном выполнении запросов и DML, то даже дядя Том говорит , что сиё средство надо рассматривать в самую последнюю очередь, когда уже всё прочее исчерпано.

Yo.!костыли в виде класик архитектуры просто динозавр на фоне mysql.в 2.5 введена архитектура SuperClassic (наглядно - тут , к примеру). Насколько я понял по прошлогодней ФБ-конференции, классика в 3.0 не будет вообще.

Yo.!что там дальше - лог транзакций и завязанная на лог дисковая подсистема. в 21 веке не иметь лога, по меньшей мере странно. из-за отсутствия лога firebird вынужден по коммиту расскладывать данные по датафайлам со всеми вытекающими для ио.Очередь на запись будет не из-за того, что лог в ФБ находится в самом же файле базы. По дефолту в ФБ установлен совершенно странный размер кэша на подключение - всего 75 страниц базы. При размере страницы 8Кб это 600 Кб- бред полный по нынешним меркам! Я пытался проинсертить 1 лям строк в таблицу с 10 индексами с таким "кэшем" - и делал это 3 часа :-) А после установки нормального значения всё влетело за 1 минуту (НЕ НА СЕРВЕРЕ! на дохлой чахотке, обычном компе 2003 года).
Кроме того, при наличии хот-замены надо вырубать Forced Writes и поставить в firebird.conf'e параметры MaxUnflushedWrites = -1, MaxUnflushedWriteTime = -1.
Наконец, назначить TempDirectories на другой диск.
Не могу вспомнить, чтобы у нас на продакшене при таких настройках запись на диск стала хотя бы раз узким местом.

Yo.! 127 одновременно выполняющихся запросов и скудность оптимизатора это просто мелочь на фоне архитектурных недочетов ...Давайте вспомним, о чём спрашивал ТС:авторчто можно поставить, что бы была проста в установке и работе , но поддерживала написание индексов и тригеров?Вряд ли он сразу после установки начнёт запускать одновременно 100500 запросов, да еще insert into t select * from t впридачу :-)
Ему нужна система, которую просто установить и которая поддерживает азы. ФБ ему должен подойти вполне.