Are there performance considerations to having 1000's of SQL Users/Logins on one SQL Server?

Question

We have a web application backed by a SQL Server database.

Up until now, we've been using a SQL Membership Provider for Application level logins. Backend calls to the SQL Server use a single SQL Account in the connection string in the Web.config

A new compliance requirement from our customer states that all application users must have their own dedicated SQL account in the background.

I've already prototyped this out and have a working version of it. The DB connection context in the application is configured for the current user per session, and in the background there's a mapping between SQLMembership account -> DatabaseUser -> Sql Server Login. The password is calculatable as a SHA1 hash of the SQLMembership User Guid.

This all works fine, but I'm wondering if there are any performance considerations on the database as a result of having 1000's of Server Logins, Database Users (+ all the GRANT permissions) that go with it.

Answer 1

The number of login IDs will not have any real impact on performance. You'll likely end up with other issues -- managing all the logins, keeping the passwords secure etc.

What will impact performance is having increased non-pooled connections to the database. Each connection will eat a small amount of RAM on the database server.

Finally, most applications do audit tracking at the application level, not at the database level. You'll need to make sure the database login is preserved throughout the application lifecycle (e.g. what happens if you do a restore?)