• First off, there's a max of 32,767 databases per instance, so you're not getting to 50,000 any time soon.

    In general, if you cluster a SQL Server instance, you move all the databases there. Any problems you have with management of your 5,000 databases will just move there. Nothing special will be added or taken away in terms of management of these databases. You'll just have the added capabilities (and headaches) of the high availability cluster. The thing to think about is, how long does it take to start your server now? All those databases going through recovery will also have to go through recovery in a failover situation. That will be a limiting factor in the amount of downtime you get from the failover.

    As to whether or not you should put 5000 databases into one database, I guess the question back at you is, why did you split it into 5000 to begin with? If that situation, whatever it is, is still in place, how will moving these things into a single database deal with that situation?

    Also:

    We also want to make sure that should we scale and grow, and we get to 50000 databases, clustering etc. will still never cause issues.

    Never is a word no one can guarantee. Clustering (and any other technology) solves some very interesting problems AND introduces wonderful new ones. You're going to have issues with clustering. Guaranteed. But, does the solutions it provide outweigh any of these issues, well, that's something you'll have to determine. Do a search for standard clustering issues so you understand what choices you're making.

    "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