Интересно, какой размер базы после которого нужно делать новую базу с вводом остатков? Каков размер базы у Вас?

(0) размер базы ни как не связан с необходимостью её сворачивания

Огласите методику подсчета размера.

Размер базы зависит только от производительности железа, на котором она крутится. Все остальное от лукавого

(1)Ну почему же?
Может у человека она на диск не влазит, а купить винт большего размера бюджет не позволяет.

(1) А как быть с тестированием и исправлением. Базу 150 Гб 1С тестирует 10 часов, что делать когда появится необходимость проведения Тестирования исправления в базе 300 Гб? Времени простоя предприятия может не хватить!

(5) Необходимость не появляется. 360 гигов.

у меня на 8.2 была база на 1.3 ТБ. Разумеется, ТиИ на ней не делали.

(5)Очень просто, купите более производительное железо и наслаждайтесь тестированием за 10минут.

(7) много! а какая конфигурация железа была?

Производительность сильно зависит от наполнения базы, а не от размера.
Т.е не факт что база размером в 2тб будет работать медленнее базы в 200гб.

(9) хм.... Это вообще виртсервер был )))

ндя с такой тенденцией терабайтные базы скоро станут не редкостью

о типовых или нетленках идет речь

Речь про файловые или скульные базы?

(13) нетленка, разумеется... Средний размер документа - 10000 строк, среднее количество документов в сутки 1500. + пару раз в неделю - документы с движениями по РС с вложениями екселя по 3-5 МБ

(1) >>  размер базы ни как не связан с необходимостью её сворачивания

+100500
Сворачивание базы - бред, оставшийся в наследство с тормозных клюшек, не способных быстро работать даже на SQL базе.

Исключения бывают. Но так на то они и исключения.

(5) >> что делать ... в базе 300 Гб?

А что люди делают в базе, 1Тб ?
Ни о каком ТИИ средствами платформы 1С естественно и речи нет.

+ к (16) Ну еще бывает чисто административная необходимость свёртки базы. Например, "спрятать" обороты по старым периодам. Когда вводить (переносить) начальные остатки в чистую базу сложнее, чем свернуть текущую.
Но это случается у параноиков, любящих всё "прятать" и там где пользователи слишком часто и много косячат - как средство избавится от косяков и бардака в учете.

типовой документооборот при хранении сканов внутри базы примерно за год дорастет до терабайта у довольно средней организации...

До этого была 80ГБ, сейчас на новом месте 6ТБ при этом достаточно нормально шевелиться

(19)
Сканы надо в отдельной базе хранить

Чето какие-то смешные цыфры в голосовалке.

Ну хранение бинарных данных в БД - отдельная история.
Вопрос сворачивания к таким базам редко имеет отношения, т.к. рост объема не связан с ростом данных, которые часто  анализируются (нужны для отчетов, при проведении документов и т.п.) и правятся.

(3) А горизонтальное масштабирование придумали дебилы, которые не догадались запросить счет на более крутой сервер?