• Just in terms of management, loads and loads of databases is a bit of a nightmare. But, from the standpoint of separation of customers, it's not a bad idea. Also, as means of performance enhancement, the concept of sharding the data is to split it into multiple storage locations (with multiple drives, etc.). So again, this isn't, on its face, a bad idea. It's primarily a question of function. Can you do what you need this way, or are you going to have to switch to different mechanisms at some point anyway.

    Also, another thing to take into account with multiple instances on your server is that you then have to share the resources, cpu & memory & disk, among these instances, which creates additional management overhead. As the amount of databases and instances grows, you're probably going to be looking at going with different servers anyway.

    BUT, this could all be premature optimization. How is the system behaving now? You're moving to high availability, but how's the performance? That's going to drive changes in what kind of system you set up. If you're not stressed yet, I sure wouldn't start making changes without a very thorough plan.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning