Не скажите, что дело просто в политике. СУБД до 1 - 2 GB создать проще. Чтобы запросы к таблам свыше этого не уходили в длинное чтение, даже на навороченных компах нужно капитально пропариться при создании СУБД. Т.е. я допускаю, что свыше этого объема СУБД, в которой не допарили, становится тормознутой, а средств для подкрутки маловато. Чтобы у разработчиков сразу не было иллюзий, имеет смысл ограничить объемы таблов. Я тут ездил в командировку настраивать Оракла. Там кластер, рэйды, но за 2 месяца данных набирается несколько миллионов. И одной таблы объем дошел до 30 млн. записей и записи по длинне таковы, что там было 13 Гб. Причем имеются постоянные транзакции и, на мой взгляд чрезмерные коммиты. И уже при старте проги выполняются запросы к этой табле - прога открывается несколько минут. Кому такое понравится? Юзера не довольны. Однако, удалось настроить до нескольких секунд. Но у Оракла кроме, средств анализа, чтобы понять что тормозит (чего ждет БД), есть еще разные возможности по оптимизации запросов, с тучами алгоритмов их выполнения и проч. подкрутками настроек. Например, если БД ждет сброса грязных блоков из кэша на диск, и есть несколько процессоров, то можно увеличить число процессов сбрасывающих эти блоки. Или если БД работает только на чтение, можно пробовать увеличить размер блока. А если бы их не было? Что было можно было сделать в той ситуации за 2 дня командировки?
Но если бы это не помогло, у Оракла есть секционирование, мат представления, чтобы с этим бороться (но это уже правда не просто настройки, а физическое проектирование БД). Если разработчики СУБД этого не сделали, то им, я думаю, имело бы смысл ограничить объем табл. парой Гб.

Cat2
Вопрос был о популярности MS SQL на ДАННОМ РЕСУРСЕ.

Уверен, что MS SQL наиболее распространенная СУБД (по крайней мере среди клиент серверных) в нашей стране, и данный ресурс это отражает.
1. Вообще, Винды наиболее популярны, и через это все майкрософтовское распространяется у нас интенсивнее продуктов сторонних по отношкнию к майкрософту производителей. Т.е. MS SQL набрал много очков на успехе виндов, и эти очки отделить от очков, которые он набирает как СУБД, не так просто. Если линукс что-то отвоюет, по крайней мере, на серверной стороне, то тогда ситуация может измениться, но не упроститься. Тогда MS SQL будет терять очки из-за худьшей переносимости на Линукс. Хотя он судя по тенденции встраивать хорошее от других СУБД и Оракла в частности (сам MS SQL именно с Ораклом любит себя сравнивать), может тоже станет со временем многоплатформенным.
2. Но запас по числу инсталяций в нашей стране у него большой (как минимум в двое он опережает ближайшего конурента по числу инсталяций Оракла, судя по этому ресурсу). А это создает потенциал для дальнейшего опережения по инсталяциям (инерция).
3. Кроме того, MS позволяет "воровать" свои продукты (Оракл - откровенно бесплатен для разработки) - влечет рост числа специалистов. Поскольку при выборе СУБД наличие большего числа специалистов в округе имеет значение, то это укрепляет его по отношению к СУБД производителей, продукты которых недоступны для малоимущих слоев населения. А эти слои и выдают в последствии основную массу спецов в нашей стране (в силу экономического положения самой страны в данное время) и все такое.
4. Ну и плюс - фин потенциал MS позволяет развивать продукт, и как СУБД он постоянно совершенствуется.

В мире он, вроде, по числу инсталяций отстает в двое от Оракла и DB2.
(MS SQL - 16%, Оракл - 34% и DB2 - 35% от всех инсталяций СУБД).
Но в целом это означает, что он уже в тройке. Т.е. СУБД, которые не в этой тройке его сложно догнать в нашей стране без каких-то неимоверных фин вливаний или гениальных технических идей.
По крайней мере, у меня сложилось такое впечатление, и, в частности, благодаря этому ресурсу.