Серж
В тоже время MBG в соседней ветке говорит о работе гиговых баз.

Сколько-то лет назад мы делали систему анализа, в которой объем данных составляет десятки гигабайт. Притом одна выборка "поднимает" до 10-ти гигабайт исходных данных. Но пользователей мало, так что один запрос может выполняться минуту-две. Сначала использовали постгрес, но он не может обрабатывать выборки, многократно превышающие доступный объем ОЗУ, так что перешли на эскулайт; в качестве бонуса получили систему, не требующую никакого обслуживания (ОС debian etch). Даже не помню, какая там версия SQLite стоит, год или два не обновляли за ненадобностью, хотя известно, что новые версии в разы быстрее.

Лучше всего смотреть тесты. Вот, например, сравнение постгреса с эскулайт:
Тестирование SQLite 3.6.17-mobigroup.2 на больших таблицах

Есть еще несколько тестов, которые стоило бы опубликовать, но очень уж мне лениво повторять это в постгресе (оно там жутко тормозит и на практике бесполезно), возможно, что просто приведу результаты для эскулайт и подскажу, как желающие могут это повторить в постгресе.

Что касается размера эскулайтовских баз, лично я тестировал _таблицы_ размером до 100 Гб (100 миллионов записей по 1 Кб каждая). На практике же использую базы не более нескольких гигабайт размером - для предотвращения блокировок лучше создать сто баз по 1 Гб, нежели одну базу на 100 Гб.

На сервере с коре квадро процессором в секунду возможно выполнение многих тысяч подключений к БД с десятками несложных запросов в каждом подключении. И вряд ли стоит думать о масштабировании, поскольку такой производительности с лихвой хватает для обеспечения работы тысяч одновременных сессий.

OnsiteМне просто для себя интересно, масштабирование возможно ли на встраиваемых БД и как оно осуществляется. )

Зависит от типа нагрузки. Если в основном происходят операции чтения, то масштабируется увеличением кол-ва процессоров и т.п. Можно и реплицировать базу на другой хост средствами файловых систем. С записью сложнее. Если операции записи допускают буфферизацию, например, коллекторы данных, то задача решается легко - настройкой интервала синхронизации баз коллекторов с основной. Когда же программная буфферизация невозможна, на помощь придут аппаратные рэйд-массивы со встроенным буфером и батарейкой, безопасно буферизующие операции доступа к БД.

Есть еще расширение для SQLite, выполняющее операции модификации БД в фоновом потоке, но я сам не пробовал. Судя по багтрекеру, возможные ошибки в этом модуле уже нашли и исправили, так что можно пользоваться. См. расширение async в апстриме. Также можно работать в режиме shared cache, но тут есть риск повредить базу при ошибках в работе с потоками приложения.

Вот выложил результаты тестов, исходя из которых я принимаю решение о разделении баз данных на части.
Degradation of indexing speed

В зависимости от доступной памяти на сервере можно получить критический размер базы, когда индексы начинают сильно "тормозить". Для 32-бит ОС и композитных индексов разумным пределом будут таблицы в 4 Гб. Полагая срок хранения данных 3 года, dataset может содержать 36 баз размером 144 Гб в сумме - при условии, что каждая БД содержит одну большую таблицу. Если этого окажется мало, можно разделить данные по неделям, что позволит управлять набором данных объемом 576 Гб. Если разделить по дням, то и 4 Тб будут обрабатываться эффективно. Разделенные таблицы можно хранить в одной БД или в разных по потребности.

Замечу, что работа с большими индексами и в других СУБД может требовать много времени, так что выбранный мною предел в 5000 секунд может быть увеличен в десятки раз, что позволит работать с огромными базами, но модификация будет выполняться в фоновом режиме. Например, если рассмотренный выше dataset разделять по часам, а по истечению суток в фоновом режиме объединять базы за каждые 24 часа в одну за сутки, можно будет работать с набором данных в десятки терабайт размером. При таких масштабах может оказаться необходимым разделить базы по хостам, благо для выборок эскулайт позволяет подключать (командой attach) удаленные базы (примонтировав удаленную ФС).