Всем привет, есть MS SQL, на котором баз 30 1С. Оправдано ли для производительности под каждую базу 1C создавать нового пользователя SQL? Или это тоже самое, если все базы подцепить на одну учетку SQL?

Никакой разницы

Зависит от прав, которые ты дашь тем пользователям...

А процесс sql один или у каждого свой?

Права выдаются  на создание, администрирование базы, но без заморочек с процессами sql (ибо не знаю где это выдается))

(0) Для производительности разницы не будет. Если конечно права у пользователей одинаковые.

Всё что видел по этому поводу.
Check-list по настройке рабочих серверов в продукционной зоне.
https://its.1c.ru/db/metod8dev#content:5899:hdoc
п.18. Имена пользователей, от которых рабочие процессы rphost работают с СУБД, в точности соответствуют именам информационных баз.
Лучше для каждой продукционной информационной базы создавать отдельного пользователя. Это нужно в первую очередь при расследовании каких-либо проблема на сервере СУБД. Если на сервере СУБД расположено более одной продукционной базы данных, может возникнуть необходимость максимально быстро расследовать проблему. При этом под рукой в отчетах или трассировках всегда будет имя пользователя, который в данный момент работает с сервером баз данных, как следствие будет и понимание, к какой именно информационной базе относится этот пользователь.

(5) спасибо большое!!! продукционная информационная база - от слова продакшн, которая боевая?)

(6) >> продукционная информационная база - от слова продакшн, которая боевая?

Да.

(5) так в мониторинге ресурсов вроде и так база написана?

Вопрос только насколько действительно это нужно.
Действительно ли может возникнуть острая необходимость настолько "максимально быстро расследовать проблему", чтобы иметь под рукой в отчетах и трассировках имя пользователя SQL.
Стоит ли ради этого заморачиваться - создавать 30 пользователей SQL под каждую базу?
Например, про мониторинг в (8) верно сказано - там имя базы и так видно.
Имени пользователя не хватает, когда возникает вопрос - какой конкретно процесс на SQL надо кильнуть в случае глобального тупняка, когда нельзя рестартовать сервер СУБД целиком. Соединения в 1С уже прибиты, на сервере 1С видимых проблем нет, а запросы в СУБД висят. И при этом на сервере несколько баз, останавливать которые нельзя. Но и там можно "вычислить" проблемный процесс - от какой он базы.

Короче. ИМХО, это крайне редко востребованная фича.