10000 tenants and Muti-Tenant Data Architecture performance?
Design a shared-everything system.  This can be deployed in a shared-nothing way i.e. put each tenant in their own database, should that prove desirable.  The extra development effort to type the additional predicate is very small and easy to do up front.  The reverse - where you re-factor a shared-nothing system to become multi-tenant - will be a significant project and difficult to get right retrospectively.  You will need some scripts or ETL packages to load / unload one tenant from a database.  This will help with size &amp; load balancing, privacy concerns and such like.

The schema-based approach has all the disadvantages of single-database and none of the advantages of multi-tenant.  You will end up with a lot of dynamic code, stored procedures will be difficult to get right and statement recompiles will be ubiquitous, increasing response times.

Invariably some of your tenants will be much larger than others.  My experience is that you will end up with a handful of tenants representing 30%-70% of the total data volume.  These will each have their own DB and, perhaps, infrastructure.  They will consume 60% of your support and maintenance time.  The others will all fit into one or two databases.

I've run development instances with roughly 1,000 databases online sharing about 8GB of memory.  This worked well enough for dev.  I'd never try this in production as the risk of problems snowballing would be too high.

If you're feeling brave you may like to experiment with auto-close on one or more database.  This will save some resources on the instance.  This is definitely not recommended.  I mention it merely as an observation.