При таком объеме и сложных запросах я бы не вспоминал про MSDN - он, фактически, embedded, а вам все-таки понадобится нормальное администрирование сервера.
Бесплатные Oracle и MS SQL отпадают из-за ограничений на объем. Oracle для бизнес-использования, даже в своей конторе (и даже в девелоперской ) - мягко говоря, не бесплатен.

Выбор у вас с такими объемами - Firebird, Postgress, DB2 Express-C.
Я - сторонник последней. Доводы - мощнейший SQL, оптимизация под OLAP, практически автоматическое администрирование, настоящий online backup с логами, бесплатна без ограничений на объем, быстрый стартап, куча документации, неплохая бесплатная среда разработки под Eclipse, мощный native XML storage.

ЩичеНичего вам ребята не поможет. Где вы сели, там и ляжете. Перейти на другой сервер - полностью переписать приложение. Или покупайте лицензию или отказывайтесь от своей программы.Ну уж! Простите, но так утверждать, не видя проекта - бред. К SQL у MSSQL имхо ближе DB2, чем Oracle. .Net DB2 поддерживает как родная, даже для VisualStudio плагин есть. Главная проблема при миграции на DB2 - перевод SP/UDF, языки сильно отличаются. И переход версионник-блокировочник, если у вас MSSQL был версионником. Остальное не так страшно. Вроде у IBM были даже какие-то утилиты портирования с Oracle и MSSQL, не знаю, насколько работоспособные.

Мимопроходящий,
MSDE, естессно. :)

ЩичеОн для всех серверов есть. Для моего Firebird тоже.Я имею в виду не .Net Data Provider, а интегрируемый в VStudio плагин для разработки БД. От разработчика СУБД. С поддержкой всех фич сервера, включая XML. И бесплатную среду для разработки и построчной отладки с клиента на сервере UDF и SP. Я использую Firebird в одном из проектов, но такого в нем и вокруг него не встречал, м.б. в платных средствах есть.
ЩичеЯзык MS SQL сильно отличаются от всех серверов. А учитывая, что клиент пронизан запросами - его нужно целиком выверять для новой платформы. Если похож - тем хуже. Разница вылезет в самый неподходящий момент. ХП переписывать, UDF тоже. Что осталось нетронутого? Считай, все придется переделывать.Все диалекты SQL сильно отличаются друг от друга. MS SQL, именно как SQL, без процедурного Transact, ближе к DB2, чем к Oracle. Хинты в DB2 обычно не нужны, к неоптимальным запросам он терпим, поэтому серьезная разница - только в многоэтажной аналитике. А выверять и править запросы клиента - не значит его переписывать, особенно если он грамотно спроектирован. Я переводил проект с Firebird на DB2, без особых проблем.
ЩичеЭто совсем не проблема в современном мире. Я свои данные и из MSSQL и из Oracle тянул гигабайтами. Есть такая древняя утилитка DataPump. Ну, на крайний случай, выливаем в CSV из стандартной MS консоли и пишем маленькую программку заливающую куда надо.Спасибо, открыли глаза, почти как Бхагават-гита. На самом деле я имел в виду автоматический перевод схемы БД вместе с SP и UDF. IBM утверждает, что оно работает, но сам я не проверял и не очень этому доверяю.
ЩичеЗря, учите матчасть. У каждого сервера свои расширения и MSSQL не исключение. DB2 никак уж не создавался для совместимости с ним.О как! Опять расширили мой кругозор самым сокровенным знанием Я предлагаю бесплатный без ограничений на размер БД вариант человеку, который спрашивал, на что можно перейти. Перечитайте первый пост. Еще раз, говорить, что проект нельзя перевести, не видя проекта - бред. Оно обычно нудно, муторно в плане тестирования, требует знания обоих диалектов SQL, но вполне реально. Особенно когда есть возможность параллельной работы двух систем.