Размер файловой базы за несколько дней стал в 2 раза больше, за счет основного файла, но выгрузка примерно такого же размера.
С чем это может быть связано? Надо ли беспоколиться?

Ни один настоящий одинэсник не забеспокоится, если у него размер станет в 2 раза больше.

(0) При обновлении, особенно на 2-3 релиза подряд файловая база легко может разростись. У меня вчера база из 5Гб. стала весить 15. После ТИИ с галкой "Сжатие таблиц" все вернулось обратно. Почему-то так происходит и кто виноват - хз, но на самом деле и пофигу

ну как почему
переименовали кучу таблиц при обновлении
добавилась новая таблица в кону
скопировались данные
старая пометилась на удаление
но место не освобождается на автомате

ну так что - сделать тестирование или пусть?
Обычно размерами администратор занимается, но тут меня спросили.

(4) это внутренняя кухня файловой БД. и это нормально.
ТиИ и вперде.

(4) В SQL тоже самое, нет причин для беспокойства

(5) помогло, кстати, вернулось к первоначальному размеру

(2) > база из 5Гб стала весить 15
А если не будет в наличии свободного места в 3,5 раза больше, чем сама база, то она иногда даже и обновиться не сможет, причём ошибка ещё и не всегда явным образом сообщает прямо о нехватке свободного места, там какая-то другая формулировка бывает (от стадии обновления зависит). Недавно была такая история, когда файловая база зачем-то работата через небезопасный костыль в виде рамдиска размером всего лишь в два с половиной раза больше, чем файл БД.

ну и само по себе, если файловая база больше в три раза, то она тяжелее читается с диска и пишется на диск, что для SSD может и некритично, а вот для обычного HDD читать/писать файл размером 5ГБ или 15 - разница ощутима.

(9) > тяжелее читается с диска и пишется на диск
Но навряд ли ведь файловая база целиком читается с диска и пишется на диск, это же всё-таки СУБД, как-никак, пусть даже и в файловом варианте. Надо полагать, она на уровне внутренних таблиц работает, и даже их, наверное, в операциях чтения-записи задействует не целиком, а как-нибудь по частям.

(10) ага, на логическом уровне все так,
только вот эти отдельные таблицы чисто физически располагаются на диске (HDD) в разных секторах и на разных дорожках.  Заметь, я же сказал, что для SSD это столь некритично.
HDD чисто физически будет "прыгать по файлу", (то есть по дорожкам и секторам) размером 5 Гб и 15 ГБ разное время. Десятки миллисекунд (среднее время позиционирования) на сотни раз.. превращаются в секунды:) Опять же, встроенный в накопитель кэш.. с большей вероятностью записи файла 5 гб окажутся в кэше накопителя, чем файла 15Гб, более разбросанного по диску.
При обычной работе  файл 1CD достаточно быстро и сильно дефрагментируется. Конечно, все зависит от конкретных условий, но в среднем (в среднем) файл размером 15 ГБ более разбросан по диску (дефрагментирован), чем размером 5 Гб.

(11) Резонно! Благодарю за разъяснение!

Включил возможность изменения в конфигурации и сразу же размер новой базы в 2 раза увеличится =)

(11) к тому же,файл на диске выделен не отдельным большим куском,а маленькими по мере роста.
Если таблица с данными занимает больше страниц (хоть часть из них меньше заполнены),то в общем случае,операций чтения потребуется больше,и тут даже на ssd будет медленнее.
Если в файле остались страницы от старых данных,то они пустые,и никак на скорость чтения и записи не влияют.