Quote Originally Posted by Serge View Post
Some genius' at microsoft thought it would be very cool to store all properties as ROWS in the table, making this profile provider completely unusable in moderate-to-heavy load environment.
Not even for a moderate load environment. I don't think it's usable in "any" environment.

Your best option for storing custom data related to a user is to make a separate table with the required fields and use the GUID user id as the primary key. Link that to the Users table provided by the default membership provider with FK relation to it's UserId field. No need to bother with creating a custom "profile provider". If you set the FK relation to CASCADE DELETE, then the associated row in your separate table will be removed automatically when a user is removed from the Users table by the membership provider.